From issues at jboss.org  Wed Jan  1 13:26:33 2014
From: issues at jboss.org (Ricardo Arguello (JIRA))
Date: Wed, 1 Jan 2014 13:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2700) Upgrade JavaMail to 1.5.1
In-Reply-To: <JIRA.12528505.1388600703369@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528505.1388600703369@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528505.1388600703369.27228.1388600793139@jira02.app.mwc.hst.phx2.redhat.com>

Ricardo Arguello created WFLY-2700:
--------------------------------------

             Summary: Upgrade JavaMail to 1.5.1
                 Key: WFLY-2700
                 URL: https://issues.jboss.org/browse/WFLY-2700
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
            Reporter: Ricardo Arguello
             Fix For: 8.0.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 issues at jboss.org  Wed Jan  1 23:47:32 2014
From: issues at jboss.org (Jeff Zhang (JIRA))
Date: Wed, 1 Jan 2014 23:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1950) Problems with connector 1.7
In-Reply-To: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499328.1377460254000.27261.1388638052773@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang commented on WFLY-1950:
----------------------------------

Hi Frank, I had test on latest Wildfly8 CR and see the code logic, it seems fine and hadn't see the issue you reported. Could you try again on the Wildfly CR? Thanks!
                
> Problems with connector 1.7
> ---------------------------
>
>                 Key: WFLY-1950
>                 URL: https://issues.jboss.org/browse/WFLY-1950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Zhang
>         Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO  [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO  [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
>         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.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
>         ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
>         ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO  [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.

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

From issues at jboss.org  Thu Jan  2 04:09:32 2014
From: issues at jboss.org (Karim AMMOUS (JIRA))
Date: Thu, 2 Jan 2014 04:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.27338.1388653772729@jira02.app.mwc.hst.phx2.redhat.com>


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

Karim AMMOUS commented on JGRP-1765:
------------------------------------

Hi Bela, 

Could you apply the enhancement without deprecating and ignoring this prop ?
TP.looback=false in our configuration.
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

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

From issues at jboss.org  Thu Jan  2 04:25:32 2014
From: issues at jboss.org (Jared Nagle (JIRA))
Date: Thu, 2 Jan 2014 04:25:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBPORTAL-2497) CR1 jdk 1.8 (b106) fresh
 install standalone.bat hangs on "Starting"
In-Reply-To: <JIRA.12528519.1388654681533@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528519.1388654681533@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528519.1388654681533.27348.1388654732774@jira02.app.mwc.hst.phx2.redhat.com>

Jared Nagle created JBPORTAL-2497:
-------------------------------------

             Summary: CR1 jdk 1.8 (b106) fresh install standalone.bat hangs on "Starting"
                 Key: JBPORTAL-2497
                 URL: https://issues.jboss.org/browse/JBPORTAL-2497
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jared Nagle


When calling the standalone.bat from a fresh install of CR1 with JAVA_HOME set to jdk 1.8.0 (b106, 20th Sep 2013) the server hangs (seems to be in an infinite loop of some sort)..


  WARNING:  JBOSS_HOME may be pointing to a different installation - unpredictable results may occur.

      JBOSS_HOME: "C:\JavaLibs\jboss-as-7.1.1.Final"

Calling "C:\JavaLibs\wildfly-8.0.0.CR1\bin\standalone.conf.bat"
Setting JAVA property to "C:\Program Files\Java\jdk1.8.0\bin\java"
===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: "C:\JavaLibs\jboss-as-7.1.1.Final"

  JAVA: "C:\Program Files\Java\jdk1.8.0\bin\java"

  JAVA_OPTS: "-XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman"

===============================================================================

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was removed in 8.0
20:23:08,464 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
20:23:08,596 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
20:23:08,634 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting


and then it hangs.

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

From issues at jboss.org  Thu Jan  2 05:13:33 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 2 Jan 2014 05:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2701) Deployed JMS resources are
 not manageable in the GUI console
In-Reply-To: <JIRA.12528522.1388657495666@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528522.1388657495666@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528522.1388657495666.27379.1388657613007@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2701:
---------------------------------

             Summary: Deployed JMS resources are not manageable in the GUI console
                 Key: WFLY-2701
                 URL: https://issues.jboss.org/browse/WFLY-2701
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


JMS resources that are part of a deployment are not manageable using the GUI console.

They are manageable using the CLI console though under 

{noformat}
 /deployment=*/subsystem=messaging/hornetq-server=* 
{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 issues at jboss.org  Thu Jan  2 05:51:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Jan 2014 05:51:34 -0500 (EST)
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.27424.1388659894247@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-490:
---------------------------------------

This feature is already included in EAP 6.2 - this issue is only still open to act as a container for any subsequent tasks identified that need to go into WildFly 8.
                
> Domain Management Role Based Access Control
> -------------------------------------------
>
>                 Key: WFLY-490
>                 URL: https://issues.jboss.org/browse/WFLY-490
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: Authorization
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Thu Jan  2 06:09:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jan 2014 06:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.27438.1388660972821@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1765:
--------------------------------

Why ? I want to reduce the number of properties, and removing loopback is on my list as we'd loop back messages by default.
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

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

From issues at jboss.org  Thu Jan  2 06:35:32 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Thu, 2 Jan 2014 06:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2702) CalendarBasedTimeoutTestCase
 failures at end/begin of the month
In-Reply-To: <JIRA.12528525.1388662462041@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528525.1388662462041@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528525.1388662462041.27465.1388662532731@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2702:
-------------------------------------

             Summary: CalendarBasedTimeoutTestCase failures at end/begin of the month
                 Key: WFLY-2702
                 URL: https://issues.jboss.org/browse/WFLY-2702
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


The referred test in the ejb module fails on end and begin of months, due to different timezones. 

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

From issues at jboss.org  Thu Jan  2 06:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 2 Jan 2014 06:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1548) Add fallback querry to
	jconsole plugin
In-Reply-To: <JIRA.12494531.1371564935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494531.1371564935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494531.1371564935000.27475.1388663612765@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Shaun Appleton <sappleto at redhat.com> changed the Status of [bug 901311|https://bugzilla.redhat.com/show_bug.cgi?id=901311] from ASSIGNED to CLOSED
                
> Add fallback querry to jconsole plugin
> --------------------------------------
>
>                 Key: WFLY-1548
>                 URL: https://issues.jboss.org/browse/WFLY-1548
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Darran Lofthouse
>              Labels: JConsole, JMX, Plugin
>             Fix For: 8.0.0.Beta1
>
>
> JConsolePlugin connecects to default port, despite chance to use proper info.
> Problem:
> Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote.
> AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990.
> However we can check for socket bindings and try to connect to proper socket.

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

From issues at jboss.org  Thu Jan  2 08:11:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 2 Jan 2014 08:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-351) KIE FileSystem resource type
 overriding does not work as reported by documentation
In-Reply-To: <JIRA.12525961.1385160001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525961.1385160001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525961.1385160001000.27592.1388668292921@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1034250|https://bugzilla.redhat.com/show_bug.cgi?id=1034250] from ON_QA to VERIFIED
                
> KIE FileSystem resource type overriding does not work as reported by documentation
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-351
>                 URL: https://issues.jboss.org/browse/DROOLS-351
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>
> When a resource is written into the KieFileSystem using the method write( path, Resource ), the resource type is ignored and it will be resolved from the file extension instead.
> That is, Example 4.10 in the Drools Official Documentation is misleading and pointing to an unimplemented feature

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

From issues at jboss.org  Thu Jan  2 08:49:33 2014
From: issues at jboss.org (Gopi Chand Uppala (JIRA))
Date: Thu, 2 Jan 2014 08:49:33 -0500 (EST)
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.27629.1388670573523@jira02.app.mwc.hst.phx2.redhat.com>


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

Gopi Chand Uppala commented on WFLY-490:
----------------------------------------

Okay. Thanks for the clarification!
                
> Domain Management Role Based Access Control
> -------------------------------------------
>
>                 Key: WFLY-490
>                 URL: https://issues.jboss.org/browse/WFLY-490
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: Authorization
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Thu Jan  2 09:03:32 2014
From: issues at jboss.org (Karim AMMOUS (JIRA))
Date: Thu, 2 Jan 2014 09:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.27633.1388671412920@jira02.app.mwc.hst.phx2.redhat.com>


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

Karim AMMOUS commented on JGRP-1765:
------------------------------------

Disable the loopback ensures as much as possible that the sender handles the message at the same time as the other receivers.
Otherwise, with loopback, there are more risks the sender processes the data much before the other members due to the network latency.

                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

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

From issues at jboss.org  Thu Jan  2 09:07:32 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Thu, 2 Jan 2014 09:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551164@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551164@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551164.27639.1388671652837@jira02.app.mwc.hst.phx2.redhat.com>

Andre Pankraz created WFLY-2703:
-----------------------------------

             Summary: Undertow Broken pipe with JSFs f:ajax and h:inputText
                 Key: WFLY-2703
                 URL: https://issues.jboss.org/browse/WFLY-2703
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Andre Pankraz




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

From issues at jboss.org  Thu Jan  2 09:09:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Thu, 2 Jan 2014 09:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.27646.1388671773379@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz updated WFLY-2703:
--------------------------------

          Description: 
Combine input text with default ajax event (leave):

<h:form id="inhaltSearch">

<h:inputText id="contentname" size="30"
	value="#{contentList.content.searchTerms}">
	<f:ajax render=":inhaltSearch" />
</h:inputText>

</h:form>

Enter value and press "Enter" (Tab works).
A short Javascript alert appears and vanishes again.

Stacktrace in Server:

14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: java.io.IOException: Broken pipe
	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
	... 9 more
    Affects Version/s: 8.0.0.CR1
          Environment: Linux, JDK 7
          Component/s: Web (Undertow)

    
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Thu Jan  2 09:17:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jan 2014 09:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.27651.1388672252710@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1765:
--------------------------------

And why would that be a problem ?
                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

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

From issues at jboss.org  Thu Jan  2 09:33:32 2014
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 2 Jan 2014 09:33:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-778) DelegatingPolicy should
 delegate refresh()
In-Reply-To: <JIRA.12528538.1388673129585@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528538.1388673129585@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528538.1388673129585.27672.1388673212739@jira02.app.mwc.hst.phx2.redhat.com>

Jan Kalina created SECURITY-778:
-----------------------------------

             Summary: DelegatingPolicy should delegate refresh()
                 Key: SECURITY-778
                 URL: https://issues.jboss.org/browse/SECURITY-778
             Project: PicketBox 
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: PicketBox
            Reporter: Jan Kalina
            Assignee: Stefan Guilhen
            Priority: Optional


DelegatingPolicy delegates non-JACC permissions to the java.security.Policy (or subclass) object.
It delegates getPermissions() and implies() methods, but not refresh() method.

It is bad, because DelegatingPolicy is used by default in current Wildfly and applications assuming standard policy provider and using normal security policy file will not refresh policies from file.

Yes, user application can bypass it by using

Policy.getPolicy().getPolicyProxy().refresh();

but this require to have "org.picketbox" in dependencies, so application on picketlink depends, or is incompatible...

This illustrate patch of my policy switching jboss extension - before patch it works only without picketlink, after it works only with picketlink: 
https://github.com/honza889/jsm-policy-subsystem/commit/f2fb420b43ac3eedbe5acde32762042e095189d6#diff-998db8f249fa4f686067810e0c894afeL41

This should resolve this one line in DelegatingPolicy class:

{code:java}
   public void refresh()
   {
         delegate.refresh();
   }
{code}

Thanks

More informations about DelegatingPolicy:
https://community.jboss.org/wiki/DelegatingPolicy
https://github.com/picketbox/picketbox-container/blob/e8dfc3e8306cdbd2329de2dc73bfa8fd61eca6cd/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/jacc/DelegatingPolicy.java#L219

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

From issues at jboss.org  Thu Jan  2 10:43:32 2014
From: issues at jboss.org (Karim AMMOUS (JIRA))
Date: Thu, 2 Jan 2014 10:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1765) TP: enable loopback by
 default and discard own multicasts
In-Reply-To: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528488.1388489261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528488.1388489261000.27720.1388677412836@jira02.app.mwc.hst.phx2.redhat.com>


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

Karim AMMOUS commented on JGRP-1765:
------------------------------------

- Use multicast allows all members to receive the data (command) at the same time. In our system, due to non-functional requirements, we must ensure the delay between the treatment done by the emitter and the receivers is less than few dozens of milliseconds.
- Useful to synchronize many actions.
- And if there is a multicast issue, the emitter *and* the receivers won't handle the message.

                
> TP: enable loopback by default and discard own multicasts
> ---------------------------------------------------------
>
>                 Key: JGRP-1765
>                 URL: https://issues.jboss.org/browse/JGRP-1765
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Enable {{TP.looback}} by default (deprecate and ignore prop): all messages sent by self are passed right to a thread pool to send them up again.
> When a multicast message sent by self is received, it is currently passed to a thread pool, de-serialized and only then discarded if loopback=true. This means that we create an unneeded buffer for de-serializationand perform de-serialization.
> SOLUTION: discard the multicast from self immediately when receiving it, in {{TP.receive()}}

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

From issues at jboss.org  Thu Jan  2 10:45:34 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 2 Jan 2014 10:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.27726.1388677534183@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2689:
---------------------------------------

Bean accessibility follows classloader isolation - a bean from a deployment is not considered accessible from a bean in a static module. We cannot change this until WELD-1536 is resolved.
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

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

From issues at jboss.org  Thu Jan  2 10:47:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Thu, 2 Jan 2014 10:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.27732.1388677653006@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz commented on WFLY-2703:
-------------------------------------

OK, happens only with

web.xml:

  <context-param>
		<param-name>javax.faces.PROJECT_STAGE</param-name>
		<param-value>Development</param-value>
  </context-param>

not with Production, SystemTest etc.
can live with that...but should be fixed ;)
                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Thu Jan  2 11:51:32 2014
From: issues at jboss.org (SBS JIRA Integration (JIRA))
Date: Thu, 2 Jan 2014 11:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.27812.1388681492884@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated WFLY-2641:
---------------------------------------

    Forum Reference: https://community.jboss.org/message/851346#851346

    
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Aslak Knutsen
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Thu Jan  2 11:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 2 Jan 2014 11:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-353) Evaluation of the RHS in a
 rule with multiple matches using noloop and update gets cut short
In-Reply-To: <JIRA.12526091.1385406731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526091.1385406731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526091.1385406731000.27814.1388681612676@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Radovan Synek <rsynek at redhat.com> changed the Status of [bug 1034094|https://bugzilla.redhat.com/show_bug.cgi?id=1034094] from ON_QA to VERIFIED
                
> Evaluation of the RHS in a rule with multiple matches using noloop and update gets cut short
> --------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-353
>                 URL: https://issues.jboss.org/browse/DROOLS-353
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> If you have a rule with both noloop and update where there are multiple matches on the LHS, the RHS only runs for first match instead of running for all matches. The following example shows the problem:
> {code}
>         @Test
>         public void testMultipleNoLoop1() {
>             String str =
>                     "import org.drools.compiler.Person\n" +
>                     "rule R no-loop\n" +
>                     "when\n" +
>                     "  String()\n" +
>                     "  $p : Person( $age : age )\n" +
>                     "then\n" +
>                     "    modify($p) { setAge( $age + 1 ) }\n" +
>                     "end\n";
>      
>             KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
>             StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
>      
>             Person mario = new Person("Mario", 38);
>      
>             ksession.insert("a");
>             ksession.insert("b");
>             ksession.insert(mario);
>             ksession.fireAllRules();
>      
>             assertEquals(40, mario.getAge());
>         }
> {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 issues at jboss.org  Thu Jan  2 11:55:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 2 Jan 2014 11:55:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.27818.1388681732762@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-2641:
-----------------------------------

Updated PR https://github.com/arquillian/arquillian-core/pull/59
                
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Aslak Knutsen
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Thu Jan  2 12:17:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 2 Jan 2014 12:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-385) KModules get added twice
In-Reply-To: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528350.1387663007000.27839.1388683052876@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1046095|https://bugzilla.redhat.com/show_bug.cgi?id=1046095] from ASSIGNED to MODIFIED
                
> KModules get added twice
> ------------------------
>
>                 Key: DROOLS-385
>                 URL: https://issues.jboss.org/browse/DROOLS-385
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mario Fusco
>
> The class loader is returning duplicate entries, as it incorrectly implements:
>     @Override
>     protected Enumeration<URL> findResources(String name) throws IOException {
>         return getParent().getResources(name);
>     }
> Deleting this method resolves the problem

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

From issues at jboss.org  Thu Jan  2 12:33:32 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 2 Jan 2014 12:33:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2637) Don't allow audit logs to be
 viewed with list-log-files and read-log-file operations
In-Reply-To: <JIRA.12527723.1386783505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527723.1386783505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527723.1386783505000.27867.1388684012897@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins commented on WFLY-2637:
-------------------------------------

Just a general comment so I don't forget, this whole thing should be looked at again. Ideally we don't want to turn {{jboss.server.log.dir}} into a generic file server directory for these commands. One option is to only allow defined file handlers files to be listed/read, but this posses security concerns.
                
> Don't allow audit logs to be viewed with list-log-files and read-log-file operations
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2637
>                 URL: https://issues.jboss.org/browse/WFLY-2637
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Currently the {{list-log-files}} and {{read-log-file}} operations will allow any file {{jboss.server.log.dir}} to be listed/viewed. Ideally only log files will be accessible, but ultimately audit logs need to definitely not be accessible.

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

From issues at jboss.org  Thu Jan  2 13:07:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 2 Jan 2014 13:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBASM-43) jsch object can not be created
In-Reply-To: <JIRA.12528358.1387732469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528358.1387732469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528358.1387732469000.27899.1388686053195@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd deleted JBASM-43:
-----------------------------

    
> jsch object can not be created
> ------------------------------
>
>                 Key: JBASM-43
>                 URL: https://issues.jboss.org/browse/JBASM-43
>             Project: JBoss AS Server Manager
>          Issue Type: Bug
>            Reporter: ali ahmed
>            Assignee: Shelly McGowan
>              Labels: jsch
>
> create a singleton ejb that contains a scheduler method which tries to create Jsch object (to create a session to list directories). the debug hangs and no exception is thrown.
> tried using of jsch-0.1.40 and jsch-0.1.50 and same result

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

From issues at jboss.org  Thu Jan  2 13:21:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Jan 2014 13:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.27919.1388686892781@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2697:
----------------------------------------

Reproducible with XP and the latest 32 bit JDK7 from ibm site as well.
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Thu Jan  2 14:21:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Jan 2014 14:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.27949.1388690492932@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2697:
----------------------------------------

Pretty sure the underlying problem has something to do with this in the Process Controller logs:

13:03:40,015 WARN  [org.jboss.as.process-controller.server] (ProcessController-threads - 3) JBAS012013: Received connection with unknown credentials from /127.0.0.1

That results in the PC closing the connection from the HC; the HC-reported error is due to that.
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Thu Jan  2 14:49:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Jan 2014 14:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.27965.1388692173609@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2697:
----------------------------------------

I think there was a recent fix in this area in relation to the format of the messages exchanged between the processes.  Could be unrelated but might be worth checking.
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Thu Jan  2 14:57:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Jan 2014 14:57:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.27967.1388692652694@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2697:
----------------------------------------

Yes, that's what I've been thinking.

The change I'm thinking of was WFLY-1988 though, and that changed the contents of the auth key created by the HC for use by server processes (replace 0x00 with 0x01.) What's failing here is the key created by the PC itself for use by the HC. The WFLY-1988 change don't seem to have touched on that.

But I think it's still somehow relevant in at least some unrelated-but-puts-me-on-the-right-trail kind of way.
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Thu Jan  2 15:43:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 2 Jan 2014 15:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.28068.1388695413338@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Mike Foley <mfoley at redhat.com> changed the Status of [bug 951993|https://bugzilla.redhat.com/show_bug.cgi?id=951993] from ON_QA to CLOSED
                
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 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 issues at jboss.org  Thu Jan  2 15:49:32 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 2 Jan 2014 15:49:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-387) NoSuchElementException on
 addKnowledgePackages when a "not" follows an "eval"
In-Reply-To: <JIRA.12528447.1388274603000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528447.1388274603000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528447.1388274603000.28104.1388695772762@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara closed DROOLS-387.
---------------------------------

    Resolution: Done

    
> NoSuchElementException on addKnowledgePackages when a "not" follows an "eval"
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-387
>                 URL: https://issues.jboss.org/browse/DROOLS-387
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: java version "1.7.0_21"
>            Reporter: Jason Saint
>            Assignee: Mark Proctor
>
> I apologize if this has already been reported, but I did not see anything in search results for which this looked like a duplicate.
> With the following 2 rules, compiling the first and adding it to a knowledge base causes subsequent package additions to fail with a NoSuchElementException.
> rule "Problem"
>   when
>     eval(true == true)
>     not String() from "Problem"
>   then
> end
> rule "Test1"
>   when
>     $test : String() from "Test"
>   then
> end
> The following java code will produce the exception on the second call to addKnowledgePackages (tried with Drools 5.4 and 5.5)
> {code}
> package com.chiprewards.droolsbug;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.io.Resource;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> /**
>  * Hello world!
>  *
>  */
> public class App 
> {
>     public static void main( String[] args )
>     {        
>         KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
>         KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
>         
>         String problem_rule = "rule \"Problem\"\n  when\n    eval(true == true)\n    not String() from \"Problem\"\n  then\nend";
>         
>         Resource resource = ResourceFactory.newByteArrayResource(problem_rule.getBytes());
>         kbuilder.add(resource, ResourceType.DRL);
>         if(kbuilder.hasErrors()) {
>             System.out.println("First rule had error parsing");
>             System.exit(1);
>         }
>         
>         kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>         
>         //Add second rule
>         
>         String next_rule = "rule \"Test\"\n  when\n    String() from \"Test\"\n  then\nend";
>         
>         resource = ResourceFactory.newByteArrayResource(next_rule.getBytes());
>         kbuilder.add(resource, ResourceType.DRL);
>         if(kbuilder.hasErrors()) {
>             System.out.println("Second rule had error parsing");
>             System.exit(1);
>         }
>         
>         kBase.addKnowledgePackages(kbuilder.getKnowledgePackages());       
>     }
> }
> {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 issues at jboss.org  Thu Jan  2 15:53:32 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 2 Jan 2014 15:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-390) Working Memory corrupted
 when modifying an object involved in a recursive query
In-Reply-To: <JIRA.12528556.1388695914441@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528556.1388695914441@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528556.1388695914441.28106.1388696012677@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-390:
-------------------------------------

             Summary: Working Memory corrupted when modifying an object involved in a recursive query
                 Key: DROOLS-390
                 URL: https://issues.jboss.org/browse/DROOLS-390
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            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 issues at jboss.org  Thu Jan  2 16:05:32 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Jan 2014 16:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2704) FORM authentication
 credentials lost on failover
In-Reply-To: <JIRA.12528557.1388696632009@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528557.1388696632009@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528557.1388696632009.28119.1388696732920@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2704:
----------------------------------

             Summary: FORM authentication credentials lost on failover
                 Key: WFLY-2704
                 URL: https://issues.jboss.org/browse/WFLY-2704
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Final


Unlike BASIC, DIGEST, and CERT authentication, FORM authentication requires an additional server side mechanism to store the credentials from the login form so that a user does not need to reauthenticate on failover.

Traditionally, clustered SSO was the mechanism of choice (see https://issues.jboss.org/browse/JBAS-1900 )
An analogous strategy is needed for 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 issues at jboss.org  Thu Jan  2 16:07:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Jan 2014 16:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.28126.1388696852843@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2697:
----------------------------------------

There is some problem here sending the auth key over stdin. The auth key is a byte[16]. For any byte in the array whose most significant bit is 1 (i.e. a negative number if converted to a signed byte) the value sent and the value received differ.

The sending side code is simply:

final Process process = builder.start();
final OutputStream stdin = process.getOutputStream();
stdin.write(authKey);
stdin.flush();

The reading code is simply:

final byte[] authKey = new byte[16];
StreamUtils.readFully(System.in, authKey);

with the util method a simple loop

{code}
        int n = 0;
        while (n < len) {
            int count = in.read(b, off + n, len - n);
            if (count < 0)
                throw MESSAGES.readBytes(n);
            n += count;
        }
{code}

I suspect this is a JVM bug of some sort as the AS code is not doing anything except making basic JDK calls.
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Thu Jan  2 17:27:32 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 2 Jan 2014 17:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.28216.1388701652990@jira02.app.mwc.hst.phx2.redhat.com>


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

Pedro Igor commented on WFLY-2689:
----------------------------------

Thanks Jozef. I'm happy that this issue is already being addressed.
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Stuart Douglas
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

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

From issues at jboss.org  Thu Jan  2 20:43:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 2 Jan 2014 20:43:33 -0500 (EST)
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.28252.1388713413410@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 resolved WFLY-1537.
-------------------------------

    Resolution: Incomplete Description


Closing due to lack of updates.
                
> 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
>      Security Level: Public(Everyone can see) 
>          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 issues at jboss.org  Thu Jan  2 20:49:34 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 2 Jan 2014 20:49:34 -0500 (EST)
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.28263.1388713774022@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved WFLY-260.
------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
                       (was: 8.0.0.Final)
       Resolution: Incomplete Description


Closing due to lack of updates
                
> Error
> -----
>
>                 Key: WFLY-260
>                 URL: https://issues.jboss.org/browse/WFLY-260
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading
>            Reporter: Pablo Ochoa
>            Assignee: David Lloyd
>
> 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 issues at jboss.org  Thu Jan  2 21:31:32 2014
From: issues at jboss.org (daisishu daisishu (JIRA))
Date: Thu, 2 Jan 2014 21:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-3505) jar-versions.xml file needs
 to be downloaded to JBoss installation folder even if the user chooses Run
 installer option.
In-Reply-To: <JIRA.12328312.1155237041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12328312.1155237041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12328312.1155237041000.28277.1388716292822@jira02.app.mwc.hst.phx2.redhat.com>


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

daisishu daisishu commented on JBAS-3505:
-----------------------------------------

for the  jboss4.0.5 ?how to download the jar-version.xml??
                
> jar-versions.xml file needs to be downloaded to JBoss installation folder even if the user chooses Run installer option.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3505
>                 URL: https://issues.jboss.org/browse/JBAS-3505
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
>         Environment: Windows All
>            Reporter: Sankarkumar Ramsankar
>            Priority: Minor
>
> jar-versions.xml file is getting downloaded only if the user choose download option. If the user choose "Run Installer" option then jar-versions.xml does not download into install folder.
> jar-versions.xml file needs to be downloaded in any type of installation either download or run installer.

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


From issues at jboss.org  Thu Jan  2 21:43:32 2014
From: issues at jboss.org (daisishu daisishu (JIRA))
Date: Thu, 2 Jan 2014 21:43:32 -0500 (EST)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBAS-9554=29_for_the_j?=
 =?utf-8?q?boss4=2E0=2E5_=EF=BC=8Chow_to_download_the_jar-version=2Exml?=
 =?utf-8?b?77yf77yf?=
In-Reply-To: <JIRA.12528564.1388716984139@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528564.1388716984139@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528564.1388716984139.28290.1388717012888@jira02.app.mwc.hst.phx2.redhat.com>

daisishu daisishu created JBAS-9554:
---------------------------------------

             Summary: for the jboss4.0.5 ?how to download the jar-version.xml??
                 Key: JBAS-9554
                 URL: https://issues.jboss.org/browse/JBAS-9554
             Project: Application Server 3  4  5 and 6
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components:  Spring integration
    Affects Versions: JBossAS-4.0.5.GA
         Environment: linux
            Reporter: daisishu daisishu
            Assignee: Ales Justin
             Fix For: JBossAS-4.0.5.GA


for the jboss4.0.5 ?how to download the jar-version.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 issues at jboss.org  Fri Jan  3 02:36:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 02:36:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-352) JUSTIFIED status is
 overridden to STATED when TMS is enabled for superclass
In-Reply-To: <JIRA.12525980.1385244947000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525980.1385244947000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525980.1385244947000.28407.1388734592928@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1034277|https://bugzilla.redhat.com/show_bug.cgi?id=1034277] from ON_QA to VERIFIED
                
> JUSTIFIED status is overridden to STATED when TMS is enabled for superclass
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-352
>                 URL: https://issues.jboss.org/browse/DROOLS-352
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.1.0.Beta1
>
>
> Enabling TMS for a class initializes the Equality Key (as STATED - otherwise the TMS would have been enabled before) for all instances of that class.
> This behavior, however, overrides the Key of any instance of a subclass which has a dedicated OTN, on which the TMS has been enabled

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

From issues at jboss.org  Fri Jan  3 02:48:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 02:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-348) Wildcard imports don't work
 for declared type fields
In-Reply-To: <JIRA.12525785.1385029194000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525785.1385029194000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525785.1385029194000.28413.1388735313023@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1033012|https://bugzilla.redhat.com/show_bug.cgi?id=1033012] from ON_QA to VERIFIED
                
> Wildcard imports don't work for declared type fields
> ----------------------------------------------------
>
>                 Key: DROOLS-348
>                 URL: https://issues.jboss.org/browse/DROOLS-348
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> Using the new KIE api the following drl doesn't compile
> {code}
> import java.util.*
> declare MyType
>     l : List
> 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 issues at jboss.org  Fri Jan  3 03:18:33 2014
From: issues at jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 3 Jan 2014 03:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4990) Cannot embed Jersey 1.13-b01
 with error: UnsupportedOperationException: JBAS011859: Naming context is
 read-only
In-Reply-To: <JIRA.12468765.1339620777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12468765.1339620777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468765.1339620777000.28456.1388737113631@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-4990:
--------------------------------------

    Forum Reference: https://community.jboss.org/message/851434#851434

    
> Cannot embed Jersey 1.13-b01 with error: UnsupportedOperationException: JBAS011859: Naming context is read-only
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-4990
>                 URL: https://issues.jboss.org/browse/AS7-4990
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.1.1.Final
>         Environment: JBoss AS 7.1.1.Final (removing the jaxrs subsystem)
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
> Linux annafi.dev 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:57:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux 
>            Reporter: Hendy Irawan
>            Assignee: Stuart Douglas
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: jerseyissue.zip
>
>
> {code}
> 03:47:22,356 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"thread-inmem-jerseywar.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"thread-inmem-jerseywar.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only
> 	at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:126)
> 	at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:116)
> 	at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:338)
> 	at org.jboss.as.naming.InitialContext.createSubcontext(InitialContext.java:229)
> 	at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:346)
> 	at javax.naming.InitialContext.createSubcontext(InitialContext.java:483)
> 	at com.sun.jersey.server.impl.cdi.CDIExtension$1.stepInto(CDIExtension.java:280)
> 	at com.sun.jersey.server.impl.cdi.CDIExtension.diveIntoJNDIContext(CDIExtension.java:267)
> 	at com.sun.jersey.server.impl.cdi.CDIExtension.createJerseyConfigJNDIContext(CDIExtension.java:273)
> 	at com.sun.jersey.server.impl.cdi.CDIExtension.initialize(CDIExtension.java:192)
> 	at com.sun.jersey.server.impl.cdi.CDIExtension.beforeBeanDiscovery(CDIExtension.java:297)
> 	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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
> 	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
> 	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
> 	at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
> 	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
> 	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46)
> 	at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:46)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:322)
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> "}}}}
> {code}
> Sample project to reproduce:
> https://github.com/ceefour/odata-sandbox/tarball/jboss-jndi-readonly-jersey
> in folder: thread-inmem-jerseywar
> The JBoss AS 7.1.1 configuration is in: thread-inmem-jerseywar/jboss/standalone-no-jaxrs.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 issues at jboss.org  Fri Jan  3 03:20:33 2014
From: issues at jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 3 Jan 2014 03:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-2755)
 java.lang.UnsupportedOperationException: JBAS011859: Naming context is
 read-only
In-Reply-To: <JIRA.12452875.1322045683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452875.1322045683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452875.1322045683000.28459.1388737233192@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-2755:
--------------------------------------

    Forum Reference: https://community.jboss.org/message/851434#851434

    
> java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only
> --------------------------------------------------------------------------------
>
>                 Key: AS7-2755
>                 URL: https://issues.jboss.org/browse/AS7-2755
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE, Naming
>    Affects Versions: 7.1.0.Beta1
>         Environment: Windows 7/ 32 bit
>            Reporter: Nick .
>            Assignee: David Lloyd
>            Priority: Blocker
>              Labels: InitialContext,, JNDI,, binding
>
> InitialContext context = new InitialContext();
> context.bind('xxxx',yyyy);
> Produces an exception as follows.
> java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-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 issues at jboss.org  Fri Jan  3 04:02:34 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 04:02:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems
	in Wildfly
In-Reply-To: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528574.1388739645000.28521.1388739754088@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz updated WFLY-2705:
--------------------------------

    Description: 
I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in  jboss-as-7.2.0.Final.)

* If i have an JSF inputText in a form (hence POST)
* and I enter "Test???"
* I get "Test?????" as result.

If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.

I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.

I have set in the environment:
  -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
An encoding filter didn't help either.

May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.

Example page for quick test:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
		xmlns:h="http://java.sun.com/jsf/html"
		xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<title>Test</title>
</h:head>
<h:body>
	<h1>Test ???</h1>
	<h:form id="test">
		<h:inputText label="Test: " value="#{test.test}">
			<f:ajax render=":test" />
		</h:inputText>
		AJAX: #{test.test}
		<br />
		<h:commandButton action="#{test.print()}" value="Print" />
	</h:form>
</h:body>
	</html>
</f:view>


package test;

import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class Test {

	private String test;

	public String getTest() {
		return test;
	}

	public void setTest(String test) {
		this.test = test;
	}

	public String print() {
		System.out.println("TEST: " + getTest());
		return "success";
	}

}

    Environment: 
CentOS
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)

    
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
>                 Key: WFLY-2705
>                 URL: https://issues.jboss.org/browse/WFLY-2705
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in  jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "Test???"
> * I get "Test?????" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
>   -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> 	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> 		xmlns:h="http://java.sun.com/jsf/html"
> 		xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> 	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> 	<title>Test</title>
> </h:head>
> <h:body>
> 	<h1>Test ???</h1>
> 	<h:form id="test">
> 		<h:inputText label="Test: " value="#{test.test}">
> 			<f:ajax render=":test" />
> 		</h:inputText>
> 		AJAX: #{test.test}
> 		<br />
> 		<h:commandButton action="#{test.print()}" value="Print" />
> 	</h:form>
> </h:body>
> 	</html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> 	private String test;
> 	public String getTest() {
> 		return test;
> 	}
> 	public void setTest(String test) {
> 		this.test = test;
> 	}
> 	public String print() {
> 		System.out.println("TEST: " + getTest());
> 		return "success";
> 	}
> }

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


From issues at jboss.org  Fri Jan  3 04:02:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 04:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems
	in Wildfly
In-Reply-To: <JIRA.12528574.1388739645118@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528574.1388739645118@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528574.1388739645118.28519.1388739753964@jira02.app.mwc.hst.phx2.redhat.com>

Andre Pankraz created WFLY-2705:
-----------------------------------

             Summary: Unicode and Umlaut problems in Wildfly
                 Key: WFLY-2705
                 URL: https://issues.jboss.org/browse/WFLY-2705
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Andre Pankraz
            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 issues at jboss.org  Fri Jan  3 04:14:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 04:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo:
 Undertow instead of JBoss or Wildfly
In-Reply-To: <JIRA.12528576.1388740415522@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528576.1388740415522@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528576.1388740415522.28529.1388740473268@jira02.app.mwc.hst.phx2.redhat.com>

Andre Pankraz created WFLY-2706:
-----------------------------------

             Summary: ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
                 Key: WFLY-2706
                 URL: https://issues.jboss.org/browse/WFLY-2706
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Andre Pankraz




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

From issues at jboss.org  Fri Jan  3 04:20:33 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 3 Jan 2014 04:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2701) Deployed JMS resources are
 not manageable in the GUI console
In-Reply-To: <JIRA.12528522.1388657495000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528522.1388657495000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528522.1388657495000.28534.1388740833239@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Mesnil commented on WFLY-2701:
-----------------------------------

Note that such JMS resources are not part of the server management model and should only appear in the "runtime" tab of the admin console
                
> Deployed JMS resources are not manageable in the GUI console
> ------------------------------------------------------------
>
>                 Key: WFLY-2701
>                 URL: https://issues.jboss.org/browse/WFLY-2701
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> JMS resources that are part of a deployment are not manageable using the GUI console.
> They are manageable using the CLI console though under 
> {noformat}
>  /deployment=*/subsystem=messaging/hornetq-server=* 
> {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 issues at jboss.org  Fri Jan  3 04:22:32 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 04:22:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo:
 Undertow instead of JBoss or Wildfly
In-Reply-To: <JIRA.12528576.1388740415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528576.1388740415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528576.1388740415000.28536.1388740952745@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz updated WFLY-2706:
--------------------------------

    Description: 
javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
"Undertow" and not with JBoss or Wildfly. Is this intentional?

Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.

So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?

I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)

JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):

void initServletContext(ServletContext context) {
		assert context != null;
		this.servletContext = context;
		final String serverInfo = servletContext.getServerInfo();
		jboss = serverInfo.contains("JBoss") ;
		glassfish = serverInfo.contains("GlassFish")
				|| serverInfo.contains("Sun Java System Application Server");
		weblogic = serverInfo.contains("WebLogic");
		jonas = System.getProperty("jonas.name") != null;

    Environment: CentOS, OpenJDK7

    
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
>                 Key: WFLY-2706
>                 URL: https://issues.jboss.org/browse/WFLY-2706
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS, OpenJDK7
>            Reporter: Andre Pankraz
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> 		assert context != null;
> 		this.servletContext = context;
> 		final String serverInfo = servletContext.getServerInfo();
> 		jboss = serverInfo.contains("JBoss") ;
> 		glassfish = serverInfo.contains("GlassFish")
> 				|| serverInfo.contains("Sun Java System Application Server");
> 		weblogic = serverInfo.contains("WebLogic");
> 		jonas = System.getProperty("jonas.name") != null;

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

From issues at jboss.org  Fri Jan  3 04:30:32 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 04:30:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo:
 Undertow instead of JBoss or Wildfly
In-Reply-To: <JIRA.12528576.1388740415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528576.1388740415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528576.1388740415000.28549.1388741432687@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz updated WFLY-2706:
--------------------------------

    Component/s: Web (Undertow)

    
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
>                 Key: WFLY-2706
>                 URL: https://issues.jboss.org/browse/WFLY-2706
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS, OpenJDK7
>            Reporter: Andre Pankraz
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> 		assert context != null;
> 		this.servletContext = context;
> 		final String serverInfo = servletContext.getServerInfo();
> 		jboss = serverInfo.contains("JBoss") ;
> 		glassfish = serverInfo.contains("GlassFish")
> 				|| serverInfo.contains("Sun Java System Application Server");
> 		weblogic = serverInfo.contains("WebLogic");
> 		jonas = System.getProperty("jonas.name") != null;

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

From issues at jboss.org  Fri Jan  3 05:36:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 05:36:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-372) InstantiationError during
 condition evaluation in Drools 6.0.0.Final
In-Reply-To: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527361.1386606563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527361.1386606563000.28604.1388745393145@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1040007|https://bugzilla.redhat.com/show_bug.cgi?id=1040007] from ON_QA to VERIFIED
                
> InstantiationError during condition evaluation in Drools 6.0.0.Final
> --------------------------------------------------------------------
>
>                 Key: DROOLS-372
>                 URL: https://issues.jboss.org/browse/DROOLS-372
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: reproduced on both jdk 6 and jdk 7
>            Reporter: Loic Albertin
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools-issue.zip
>
>
> Kindly find bellow the initial discussion from rules-user at list.jboss.org
> In addition I attach a sample project that reproduce the error. 
> To run it simply type 'mvn clean install exec:java'.
> An interesting thing is that on my environment the issue always appears at the 21st insertion. 
> {quote}
> Hi all,
> I'm migrating from an old Drools 5.1 version to 6.0.0.Final. Sometimes (I don't really get under which conditions as sometimes it works), I'm facing an InstantiationError exception when I insert a fact into a stateful kie session. This exception is thrown by a generated class named ConditionEvaluator<UUID> which doesn't help for debugging!
> The inserted object is a basic POJO (named JasmineEventEB) except for an attribute named "value" which accept any "Serializable" object and which is causing the issue.
> The rule condition is quite simple
> $e : JasmineEventEB(probe == "Button:pris" && value == "1")
> In debugging I found that it failed when evaluating the value == "1" part. I can also confirm that the value for the actually inserted JasmineEventEB is a string.
> The stacktrace is:
> {noformat}
> java.lang.InstantiationError: java.io.Serializable
>         at ConditionEvaluatorae1a73837e8146bda23004a0450e2e52.evaluate(Unknown Source)
>         at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:212)
>         at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:169)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
>         at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:138)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
>         at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:377)
>         at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
>         at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
>         at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1149)
>         at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1093)
>         at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> {noformat}
> I tested both with the java and mvel dialect with the same result.
> Does someone has already encountered this kind of error?
> If you need more details or clarifications please let me know.
> Thanks & regards,
> Lo?c  
> {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 issues at jboss.org  Fri Jan  3 05:46:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 05:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems
	in Wildfly
In-Reply-To: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528574.1388739645000.28619.1388745993639@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2705.
----------------------------------

      Assignee: Jozef Hartinger  (was: Stuart Douglas)
    Resolution: Duplicate Issue


Looks like you are hitting WFLY-2531

There are a couple of workarounds you can do. You can either map the CDI conversation filter, or set the default encoding to UTF-8 at either the server level or by using jboss-web.xml. 

Alternatively if you are not using CDI you can remove the weld subsystem or exclude it using jboss-deployment-structure.xml
                
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
>                 Key: WFLY-2705
>                 URL: https://issues.jboss.org/browse/WFLY-2705
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
>            Reporter: Andre Pankraz
>            Assignee: Jozef Hartinger
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in  jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "Test???"
> * I get "Test?????" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
>   -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> 	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> 		xmlns:h="http://java.sun.com/jsf/html"
> 		xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> 	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> 	<title>Test</title>
> </h:head>
> <h:body>
> 	<h1>Test ???</h1>
> 	<h:form id="test">
> 		<h:inputText label="Test: " value="#{test.test}">
> 			<f:ajax render=":test" />
> 		</h:inputText>
> 		AJAX: #{test.test}
> 		<br />
> 		<h:commandButton action="#{test.print()}" value="Print" />
> 	</h:form>
> </h:body>
> 	</html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> 	private String test;
> 	public String getTest() {
> 		return test;
> 	}
> 	public void setTest(String test) {
> 		this.test = test;
> 	}
> 	public String print() {
> 		System.out.println("TEST: " + getTest());
> 		return "success";
> 	}
> }

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


From issues at jboss.org  Fri Jan  3 05:48:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 05:48:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems
	in Wildfly
In-Reply-To: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528574.1388739645000.28622.1388746112699@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated WFLY-2705:
---------------------------------

    Component/s: CDI / Weld
                     (was: Web (Undertow))

    
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
>                 Key: WFLY-2705
>                 URL: https://issues.jboss.org/browse/WFLY-2705
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
>            Reporter: Andre Pankraz
>            Assignee: Jozef Hartinger
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in  jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "Test???"
> * I get "Test?????" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
>   -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> 	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> 		xmlns:h="http://java.sun.com/jsf/html"
> 		xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> 	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> 	<title>Test</title>
> </h:head>
> <h:body>
> 	<h1>Test ???</h1>
> 	<h:form id="test">
> 		<h:inputText label="Test: " value="#{test.test}">
> 			<f:ajax render=":test" />
> 		</h:inputText>
> 		AJAX: #{test.test}
> 		<br />
> 		<h:commandButton action="#{test.print()}" value="Print" />
> 	</h:form>
> </h:body>
> 	</html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> 	private String test;
> 	public String getTest() {
> 		return test;
> 	}
> 	public void setTest(String test) {
> 		this.test = test;
> 	}
> 	public String print() {
> 		System.out.println("TEST: " + getTest());
> 		return "success";
> 	}
> }

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


From issues at jboss.org  Fri Jan  3 05:54:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 05:54:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2706) ServletContext.getServerInfo:
 Undertow instead of JBoss or Wildfly
In-Reply-To: <JIRA.12528576.1388740415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528576.1388740415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528576.1388740415000.28626.1388746472822@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated WFLY-2706:
---------------------------------

    Assignee: Stuart Douglas

    
> ServletContext.getServerInfo: Undertow instead of JBoss or Wildfly
> ------------------------------------------------------------------
>
>                 Key: WFLY-2706
>                 URL: https://issues.jboss.org/browse/WFLY-2706
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS, OpenJDK7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> javax.servlet.ServletContext.getServerInfo() identifies Wildfly with:
> "Undertow" and not with JBoss or Wildfly. Is this intentional?
> Some frameworks or extensions (e.g. JavaMelody) use this server info to provide application server specific behaviour.
> So Wildfly (or the newer JBoss AS) is quite different to past versions and this must not be the wrong step to tell something different here, but providing the embedded Servlet Container "Undertow" as response might not be intentional?
> I would suggest to show something with "JBoss" even though Wildfly is the community version name (BTW great move...who wants to have wild flies in his data center...where is our swatter)
> JavaMelody example code, triggered by HttpSessionListener.contextInitialized(ServletContextEvent event) -> initServletContext(event.getServletContext()):
> void initServletContext(ServletContext context) {
> 		assert context != null;
> 		this.servletContext = context;
> 		final String serverInfo = servletContext.getServerInfo();
> 		jboss = serverInfo.contains("JBoss") ;
> 		glassfish = serverInfo.contains("GlassFish")
> 				|| serverInfo.contains("Sun Java System Application Server");
> 		weblogic = serverInfo.contains("WebLogic");
> 		jonas = System.getProperty("jonas.name") != null;

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

From issues at jboss.org  Fri Jan  3 06:06:33 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 3 Jan 2014 06:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-391) Support class literals with
 complex constraints and custom evaluators
In-Reply-To: <JIRA.12528582.1388747122442@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528582.1388747122442@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528582.1388747122442.28635.1388747193135@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-391:
-------------------------------------

             Summary: Support class literals with complex constraints and custom evaluators
                 Key: DROOLS-391
                 URL: https://issues.jboss.org/browse/DROOLS-391
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final, 5.5.1.Final
            Reporter: Davide Sottara
            Assignee: Mario Fusco


The following is supported, when A is a class name:
{code} Pattern( this op A ) {code}

But the following fails with a CCE
{code} Pattern( this op A || this op B ) {code}
when it tries to resolve A as a field of the class Pattern

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

From issues at jboss.org  Fri Jan  3 06:10:32 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 3 Jan 2014 06:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-392) KIE APIs do now allow to
 configure the Belief System type
In-Reply-To: <JIRA.12528583.1388747326039@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528583.1388747326039@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528583.1388747326039.28638.1388747432743@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-392:
-------------------------------------

             Summary: KIE APIs do now allow to configure the Belief System type
                 Key: DROOLS-392
                 URL: https://issues.jboss.org/browse/DROOLS-392
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


BeliefSystemTypeOption is a valid SingleValueKieSessionOption, but the internal class SessionConfiguration ignores 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 issues at jboss.org  Fri Jan  3 06:10:32 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Fri, 3 Jan 2014 06:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-392) KIE APIs do not allow to
 configure the Belief System type
In-Reply-To: <JIRA.12528583.1388747326000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528583.1388747326000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528583.1388747326000.28640.1388747432853@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara updated DROOLS-392:
----------------------------------

    Summary: KIE APIs do not allow to configure the Belief System type  (was: KIE APIs do now allow to configure the Belief System type)

    
> KIE APIs do not allow to configure the Belief System type
> ---------------------------------------------------------
>
>                 Key: DROOLS-392
>                 URL: https://issues.jboss.org/browse/DROOLS-392
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>
> BeliefSystemTypeOption is a valid SingleValueKieSessionOption, but the internal class SessionConfiguration ignores 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 issues at jboss.org  Fri Jan  3 06:12:32 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 06:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2707) Filter.destroy() not called
 for undeployment
In-Reply-To: <JIRA.12528584.1388747435393@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528584.1388747435393@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528584.1388747435393.28643.1388747552695@jira02.app.mwc.hst.phx2.redhat.com>

Andre Pankraz created WFLY-2707:
-----------------------------------

             Summary: Filter.destroy() not called for undeployment
                 Key: WFLY-2707
                 URL: https://issues.jboss.org/browse/WFLY-2707
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
         Environment: CentOs/OpenJDK 7
            Reporter: Andre Pankraz


ServletContextListener.contextDestroyed() is called reliably at undeployment time.
But the destroy() methods of  javax.servlet.Filters are never called.

The filter is not explicetely in the web.xml, it's automatically detected and initialized via init() at deployment, but destroy() is never called.

JavaMelody cannot shutdown it's timers because of this:
See last remarks in http://code.google.com/p/javamelody/issues/detail?id=360

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

From issues at jboss.org  Fri Jan  3 06:12:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 3 Jan 2014 06:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2707) Filter.destroy() not called
 for undeployment
In-Reply-To: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528584.1388747435000.28646.1388747552848@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2707:
------------------------------

    Component/s: Web (Undertow)

    
> Filter.destroy() not called for undeployment
> --------------------------------------------
>
>                 Key: WFLY-2707
>                 URL: https://issues.jboss.org/browse/WFLY-2707
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOs/OpenJDK 7
>            Reporter: Andre Pankraz
>
> ServletContextListener.contextDestroyed() is called reliably at undeployment time.
> But the destroy() methods of  javax.servlet.Filters are never called.
> The filter is not explicetely in the web.xml, it's automatically detected and initialized via init() at deployment, but destroy() is never called.
> JavaMelody cannot shutdown it's timers because of this:
> See last remarks in http://code.google.com/p/javamelody/issues/detail?id=360

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

From issues at jboss.org  Fri Jan  3 07:10:32 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 3 Jan 2014 07:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems
	in Wildfly
In-Reply-To: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528574.1388739645000.28709.1388751032893@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz commented on WFLY-2705:
-------------------------------------

Thanks for the hint, the workaround to explitely use the CharacterEncodingFilter and adding the CDI Filter behind this worked.

Strange that it works for JBoss 7.2 and Wildfly with AJAX though.
I hope there is a better solution in the future.
I found some hints to the new attribute <servlet-container  ... default-encoding="UTF-8"> but my version (from git yesterday) didn't know about it yet.
Thanks again!

                
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
>                 Key: WFLY-2705
>                 URL: https://issues.jboss.org/browse/WFLY-2705
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
>            Reporter: Andre Pankraz
>            Assignee: Jozef Hartinger
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in  jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "Test???"
> * I get "Test?????" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
>   -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> 	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> 		xmlns:h="http://java.sun.com/jsf/html"
> 		xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> 	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> 	<title>Test</title>
> </h:head>
> <h:body>
> 	<h1>Test ???</h1>
> 	<h:form id="test">
> 		<h:inputText label="Test: " value="#{test.test}">
> 			<f:ajax render=":test" />
> 		</h:inputText>
> 		AJAX: #{test.test}
> 		<br />
> 		<h:commandButton action="#{test.print()}" value="Print" />
> 	</h:form>
> </h:body>
> 	</html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> 	private String test;
> 	public String getTest() {
> 		return test;
> 	}
> 	public void setTest(String test) {
> 		this.test = test;
> 	}
> 	public String print() {
> 		System.out.println("TEST: " + getTest());
> 		return "success";
> 	}
> }

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


From issues at jboss.org  Fri Jan  3 07:17:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 07:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2707) Filter.destroy() not called
 for undeployment
In-Reply-To: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528584.1388747435000.28728.1388751452702@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2707:
------------------------------------

    Assignee: Stuart Douglas

    
> Filter.destroy() not called for undeployment
> --------------------------------------------
>
>                 Key: WFLY-2707
>                 URL: https://issues.jboss.org/browse/WFLY-2707
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOs/OpenJDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> ServletContextListener.contextDestroyed() is called reliably at undeployment time.
> But the destroy() methods of  javax.servlet.Filters are never called.
> The filter is not explicetely in the web.xml, it's automatically detected and initialized via init() at deployment, but destroy() is never called.
> JavaMelody cannot shutdown it's timers because of this:
> See last remarks in http://code.google.com/p/javamelody/issues/detail?id=360

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

From issues at jboss.org  Fri Jan  3 07:19:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 07:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2431) Console flipping to
 "jboss-ejb-policy" when select other security domain
In-Reply-To: <JIRA.12510975.1383331118000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12510975.1383331118000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12510975.1383331118000.28731.1388751572846@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2431:
------------------------------------------

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

    
> Console flipping to "jboss-ejb-policy" when select other security domain 
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2431
>                 URL: https://issues.jboss.org/browse/WFLY-2431
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.Beta1
>         Environment: Linux x64 (Fedora), server started with standalone.xml profile
>            Reporter: dometec
>            Assignee: Heiko Braun
>            Priority: Minor
>              Labels: Console, Web
>         Attachments: wildfly-console.flipping.ogv
>
>
> Console flipping to "jboss-ejb-policy" when select other 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 issues at jboss.org  Fri Jan  3 07:23:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 07:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2707) Filter.destroy() not called
 for undeployment
In-Reply-To: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528584.1388747435000.28747.1388751812824@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2707:
--------------------------------------

Fixed in upstream undertow
                
> Filter.destroy() not called for undeployment
> --------------------------------------------
>
>                 Key: WFLY-2707
>                 URL: https://issues.jboss.org/browse/WFLY-2707
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOs/OpenJDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> ServletContextListener.contextDestroyed() is called reliably at undeployment time.
> But the destroy() methods of  javax.servlet.Filters are never called.
> The filter is not explicetely in the web.xml, it's automatically detected and initialized via init() at deployment, but destroy() is never called.
> JavaMelody cannot shutdown it's timers because of this:
> See last remarks in http://code.google.com/p/javamelody/issues/detail?id=360

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

From issues at jboss.org  Fri Jan  3 07:47:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 07:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2688) jsp with empty content prolog
	gives error
In-Reply-To: <JIRA.12528413.1387960062000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528413.1387960062000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528413.1387960062000.28794.1388753253171@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2688:
--------------------------------------

Fixed in upstream Undertow
                
> jsp with empty content prolog gives error
> -----------------------------------------
>
>                 Key: WFLY-2688
>                 URL: https://issues.jboss.org/browse/WFLY-2688
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: fiorenzo pizza
>            Assignee: Stuart Douglas
>
> i f you deploy  jsp pages with 1 empty row  and after the content, like:
> --------------------
> <%  
>   response.sendRedirect("first.jsf");  
> %>  
> ----------------------------------
> the error in the log is:
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /index.jsp: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
>         at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:298) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:126) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:188) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:115) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:74) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jsp.index_jsp._jspService(index_jsp.java:66)
>         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

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

From issues at jboss.org  Fri Jan  3 07:49:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 07:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2699) liferay portal does not work
In-Reply-To: <JIRA.12528492.1388497049000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528492.1388497049000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528492.1388497049000.28800.1388753373004@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2699:
--------------------------------------

Sounds like it has something to do with the content-length for compression being wrong. 

How is compression handled? It is a custom filter in Liferay?
                
> liferay portal does not work
> ----------------------------
>
>                 Key: WFLY-2699
>                 URL: https://issues.jboss.org/browse/WFLY-2699
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha? Zegan
>            Assignee: Stuart Douglas
>
> Hello.
> I have commpiled the full wildfly package and set gerrit, jenkins, and the nexus repo manager on it, all works perfectly.
> The problem:
> I tried to deploy liferay on the same instance.
> I did everything and then deployed the webapp.
> The deploy was successful, but it didn't work.
> I have the appserver behind apache reverse proxy, trying to load a page displays error 502 proxy error.
> I checked with telnet what happens by telnetting to the backend appserver and sending a GET request for /.
> The response was incorrect, I got the expected document but without the status line and headers, that makes it clear why apache sait error 502.
> Liferay probably works with jboss as 7 and tomcat/etc, so I think undertow must have something to do with 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 issues at jboss.org  Fri Jan  3 08:03:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 08:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2699) liferay portal does not work
In-Reply-To: <JIRA.12528492.1388497049000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528492.1388497049000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528492.1388497049000.28920.1388754212952@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2699:
--------------------------------------

So looking at the code here:

http://grepcode.com/file/repo1.maven.org/maven2/com.liferay.portal/portal-impl/6.0.6/com/liferay/portal/servlet/filters/gzip/GZipResponse.java#GZipResponse

One possible issue is that setContentLength(long) is not overridden, so if portlet uses this method compression will not work. This seems unlikely though. 

Basically we need to figure out how the content length is being set. Undertow will automatically set a content length header if the output stream is closed without being flushed, and the response fits entirely in the buffer, however I can't see how that would be the cause. 
                
> liferay portal does not work
> ----------------------------
>
>                 Key: WFLY-2699
>                 URL: https://issues.jboss.org/browse/WFLY-2699
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha? Zegan
>            Assignee: Stuart Douglas
>
> Hello.
> I have commpiled the full wildfly package and set gerrit, jenkins, and the nexus repo manager on it, all works perfectly.
> The problem:
> I tried to deploy liferay on the same instance.
> I did everything and then deployed the webapp.
> The deploy was successful, but it didn't work.
> I have the appserver behind apache reverse proxy, trying to load a page displays error 502 proxy error.
> I checked with telnet what happens by telnetting to the backend appserver and sending a GET request for /.
> The response was incorrect, I got the expected document but without the status line and headers, that makes it clear why apache sait error 502.
> Liferay probably works with jboss as 7 and tomcat/etc, so I think undertow must have something to do with 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 issues at jboss.org  Fri Jan  3 08:07:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 08:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work
 with Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.28923.1388754452852@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2690:
--------------------------------------

Do you have a reproducer? 

I am pretty sure this is a weld issue, but it should be possible for me to work around it, however it would be easier if you have a ready made reproducer I can test out. 
                
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Fri Jan  3 08:43:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 08:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2705) Unicode and Umlaut problems
	in Wildfly
In-Reply-To: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528574.1388739645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528574.1388739645000.28964.1388756613119@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2705:
--------------------------------------

default-encoding should be working in CR1. What config where you using?
                
> Unicode and Umlaut problems in Wildfly
> --------------------------------------
>
>                 Key: WFLY-2705
>                 URL: https://issues.jboss.org/browse/WFLY-2705
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOS
> java version "1.7.0_45"
> OpenJDK Runtime Environment (rhel-2.4.3.2.el6_4-x86_64 u45-b15)
>            Reporter: Andre Pankraz
>            Assignee: Jozef Hartinger
>
> I think I'm doing something wrong if this is really a CR1, but I cannot get UTF working properly on Wildfly. (It works fine in same environment and same settings/code in  jboss-as-7.2.0.Final.)
> * If i have an JSF inputText in a form (hence POST)
> * and I enter "Test???"
> * I get "Test?????" as result.
> If I provide a <f:ajax render...> on this field, the ajax rendering creates the proper response, but if I submit the data I always get the wrong encoded result.
> I created a minimalistic web app without any additional libs with just one JSF test page (see below). It works in jboss as 7.2 final but not in Wildfly CR1.
> I have set in the environment:
>   -Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8
> An encoding filter didn't help either.
> May be I'm doing something wrong here, but I have seen quite some other bugs that don't really speak for a "Release-Candidate" so it might really be an issue? Have you really tried to deploy at least 2 or 3 bigger JSF apps onto this new version? Will add some more reports.
> Example page for quick test:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <f:view encoding="UTF-8" xmlns:f="http://java.sun.com/jsf/core">
> 	<html lang="de" xmlns="http://www.w3.org/1999/xhtml"
> 		xmlns:h="http://java.sun.com/jsf/html"
> 		xmlns:ui="http://java.sun.com/jsf/facelets">
> <h:head>
> 	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> 	<title>Test</title>
> </h:head>
> <h:body>
> 	<h1>Test ???</h1>
> 	<h:form id="test">
> 		<h:inputText label="Test: " value="#{test.test}">
> 			<f:ajax render=":test" />
> 		</h:inputText>
> 		AJAX: #{test.test}
> 		<br />
> 		<h:commandButton action="#{test.print()}" value="Print" />
> 	</h:form>
> </h:body>
> 	</html>
> </f:view>
> package test;
> import javax.enterprise.context.RequestScoped;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class Test {
> 	private String test;
> 	public String getTest() {
> 		return test;
> 	}
> 	public void setTest(String test) {
> 		this.test = test;
> 	}
> 	public String print() {
> 		System.out.println("TEST: " + getTest());
> 		return "success";
> 	}
> }

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


From issues at jboss.org  Fri Jan  3 10:00:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 10:00:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-350) Incremental compilation is
 not correctly synchronized
In-Reply-To: <JIRA.12525912.1385128087000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525912.1385128087000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525912.1385128087000.29269.1388761233396@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1033612|https://bugzilla.redhat.com/show_bug.cgi?id=1033612] from ON_QA to VERIFIED
                
> Incremental compilation is not correctly synchronized
> -----------------------------------------------------
>
>                 Key: DROOLS-350
>                 URL: https://issues.jboss.org/browse/DROOLS-350
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> Incremental compilation is not correctly synchronized and then a kiesession can fire when the underlying rule base is in an inconsistent state. The test case below shows the problem
> {code}
>     @Test(timeout = 10000)
>     public void testIncrementalCompilationSynchronization() throws Exception {
>         final KieServices kieServices = KieServices.Factory.get();
>         ReleaseId releaseId = kieServices.newReleaseId("org.kie.test", "sync-scanner-test", "1.0.0");
>         createAndDeployJar( kieServices, releaseId, createDRL("rule0") );
>         final KieContainer kieContainer = kieServices.newKieContainer(releaseId);
>         KieSession kieSession = kieContainer.newKieSession();
>         List<String> list = new ArrayList<String>();
>         kieSession.setGlobal("list", list);
>         kieSession.fireAllRules();
>         kieSession.dispose();
>         assertEquals(1, list.size());
>         Thread t = new Thread(new Runnable() {
>             @Override
>             public void run() {
>                 for (int i = 1; i < 10; i++) {
>                     ReleaseId releaseId = kieServices.newReleaseId("org.kie.test", "sync-scanner-test", "1.0." + i);
>                     createAndDeployJar( kieServices, releaseId, createDRL("rule" + i) );
>                     kieContainer.updateToVersion(releaseId);
>                 }
>             }
>         });
>         t.setDaemon(true);
>         t.start();
>         while (true) {
>             kieSession = kieContainer.newKieSession();
>             list = new ArrayList<String>();
>             kieSession.setGlobal("list", list);
>             kieSession.fireAllRules();
>             kieSession.dispose();
>             assertEquals(1, list.size());
>             if (list.get(0).equals("rule9")) {
>                 break;
>             }
>         }
>     }
>     private String createDRL(String ruleName) {
>         return "package org.kie.test\n" +
>                "global java.util.List list\n" +
>                "rule " + ruleName + "\n" +
>                "when\n" +
>                "then\n" +
>                "list.add( drools.getRule().getName() );\n" +
>                "end\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 issues at jboss.org  Fri Jan  3 10:10:32 2014
From: issues at jboss.org (Matus Zamborsky (JIRA))
Date: Fri, 3 Jan 2014 10:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work
 with Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.29291.1388761832935@jira02.app.mwc.hst.phx2.redhat.com>


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

Matus Zamborsky commented on WFLY-2690:
---------------------------------------

Hello,
I have one (will upload it shortly). It really is a problem of weld. I went a little bit deeper and even find the problem. The problem is in 
[org.jboss.weld.annotated.slim.AnnotatedTypeIdentifier | https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/annotated/slim/AnnotatedTypeIdentifier.java]. Deep down it is used as a key in caching Annotated types and as you can see from sources of this class, it uses only className (and other attributes) to distinguish between classes. But Wildfly uses different class loaders for every JSP (and included tags). 

The problem manifests as casting exception from class A1 to class A2 (where A1 and A2 have the same class name but are loaded with different classloaders).

I rewrote AnnotatedTypeIdentifier so it uses the class object instead of className and it looks promising (no exceptions). But I am not a weld developer, and don't really know if it wont have any other consequences.
                
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Fri Jan  3 10:36:36 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 10:36:36 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-358) KieModule resulting from an
 incremental compilation cannot be used to update a KieContainer
In-Reply-To: <JIRA.12526543.1385728167000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526543.1385728167000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526543.1385728167000.29354.1388763396427@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1036096|https://bugzilla.redhat.com/show_bug.cgi?id=1036096] from ON_QA to VERIFIED
                
> KieModule resulting from an incremental compilation cannot be used to update a KieContainer
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-358
>                 URL: https://issues.jboss.org/browse/DROOLS-358
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> Programmatic incremental compilation modifies the existing KieModule in place instead of creating a new one. This makes impossible to upgrade a KieContainer with the kieModulre resulting from the incremental compilation. In fact in this case the new KieModule is identical (same instance) to the old one making the automatic KieModule comparison useless.

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

From issues at jboss.org  Fri Jan  3 11:26:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Jan 2014 11:26:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.29410.1388766394400@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-2498:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Heiko Braun)

    
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan  3 11:26:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Jan 2014 11:26:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.29414.1388766394558@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-2498:
-----------------------------------

    Component/s: Domain Management

    
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan  3 11:26:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 3 Jan 2014 11:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work
 with Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.29394.1388766393635@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2690:
------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)


Jozef, any chance that you could have a look at this? Basically this issue is that Jasper creates multiple classes with the same name but different class loaders, and Weld can't really handle it (see the earlier comment about the underlying cause). 
                
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Fri Jan  3 11:26:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Jan 2014 11:26:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.29405.1388766394119@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2498:
----------------------------------------

[~heiko.braun] I am going to take ownership of this one for the moment - sounds to be related to the server side of the redirect handling at the moment - I will let you know if there is anything on the console side.
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>            Reporter: Chris Dolphy
>            Assignee: Heiko Braun
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan  3 12:04:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 12:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.29452.1388768672934@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1039676|https://bugzilla.redhat.com/show_bug.cgi?id=1039676] from ON_QA to ASSIGNED
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Fri Jan  3 12:10:33 2014
From: issues at jboss.org (Jeremy Whiting (JIRA))
Date: Fri, 3 Jan 2014 12:10:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.29469.1388769033065@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeremy Whiting resolved JBWEB-281.
----------------------------------

    Resolution: Done


This was resolved, FishEye was showing misleading information for the 7.3 code branch.
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Fri Jan  3 12:28:33 2014
From: issues at jboss.org (Matus Zamborsky (JIRA))
Date: Fri, 3 Jan 2014 12:28:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work
 with Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.29488.1388770113098@jira02.app.mwc.hst.phx2.redhat.com>


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

Matus Zamborsky commented on WFLY-2690:
---------------------------------------

Here is the reproducer. Its a simple web app, not a test case (sorry for that). 

https://github.com/backslash47/wfly2690.git

To reproduce the error, try http://localhost:8080/wfly2690/index.jsp and then http://localhost:8080/wfly2690/index2.jsp

As of the possible fix I propose, please, look at this [Commit | https://github.com/backslash47/core/commit/22005cb9b9f561949f8490286c28b88ad3d9ca64]

                
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Fri Jan  3 13:20:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Jan 2014 13:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.29530.1388773233465@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-2498:
-----------------------------------

    Fix Version/s: 8.0.0.Final

    
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan  3 14:24:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 14:24:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.29560.1388777072820@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1029687|https://bugzilla.redhat.com/show_bug.cgi?id=1029687] from NEW to POST
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan  3 16:48:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 16:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-898)
	SharedLocalYieldingLockManager.LocalLock
In-Reply-To: <JIRA.12479431.1353286224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479431.1353286224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479431.1353286224000.29648.1388785713239@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Ferraro <paul.ferraro at redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from NEW to POST
                
> SharedLocalYieldingLockManager.LocalLock
> ----------------------------------------
>
>                 Key: WFLY-898
>                 URL: https://issues.jboss.org/browse/WFLY-898
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: MJ Kim
>            Assignee: Paul Ferraro
>
> Hi,
>  
> Recently my system has been in the QA. (includes Stress test, Endurance test)
> During the endurance test, I found that the heap space was getting exausted, and not removed after full gc.
> When the heap space got close to 90%, the gabage collection was happend every 2 min, and my system was stopped reponding.
> The heap space was not cleaned up, nevertheless I ended the test (no request during a few hours)
>  
>  
> I downloaded some heap dumps, and found that the SharedLocalYieldingLockManage.LocalLock() resided much of heap space. (above 60%)
> I think the session expiration doesn't operate porperly.
>  
> If the SessionBasesClusteredSession class raises the expiration signals with "LocalOnly=True", the lock would not be removed.
>  
> Addionally, I reviewed our source code and did a leakage discory test, anything was matter.
>  
> Here is my environment. If you want to see my standalone.xml, please post a reply thread.
>  
> <Cluster>
> - 8 JVM (4 machine, each 2)
> - JDK : 1.6u31
> - OS : Amazon Linux 64bit
> - JGroups : FILE_PING (The shared storage is GlusterFS volume)
> - Infinispan operation mode : L1 + Distribution / ASYNC / expiration 1min
> - Session handling : web.xml (expiration every 1min)
>    (Originally our setting was 30 min. Beacuse the load generator was sending too many requests with new session, I lowered the threshold to 1min)
> - Source code : 7.1.3 Final tag (downloaded from Github)

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

From issues at jboss.org  Fri Jan  3 16:48:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 16:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-406) Redesign web session clustering
In-Reply-To: <JIRA.12489848.1366310318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489848.1366310318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489848.1366310318000.29650.1388785713322@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Ferraro <paul.ferraro at redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from NEW to POST
                
> Redesign web session clustering
> -------------------------------
>
>                 Key: WFLY-406
>                 URL: https://issues.jboss.org/browse/WFLY-406
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha2
>
>
> The current web session replication code has been around for ages and suffers from a number of issues:
> * By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
> * Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
> * Extra logic/locking is required to invalidate the local session map is required per request
> * AtomicMaps, on which the current implementation relies, have proven buggy
> * Session access outside of the scope of the replication valve is possible and problematic
> * Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
> * The current code base is tightly coupled to JBoss Web.  Migrating the code to support Undertow will inevitably introduce issues and code duplication.
> The new design will incorporate a proper SPI for the servlet container.  Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.

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

From issues at jboss.org  Fri Jan  3 17:04:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Jan 2014 17:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1351) Incorrect exception handling
 in CoreGroupCommunicationService#handle
In-Reply-To: <JIRA.12491886.1368648070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491886.1368648070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491886.1368648070000.29660.1388786672944@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Ferraro <paul.ferraro at redhat.com> changed the Status of [bug 963448|https://bugzilla.redhat.com/show_bug.cgi?id=963448] from NEW to POST
                
> Incorrect exception handling in CoreGroupCommunicationService#handle
> --------------------------------------------------------------------
>
>                 Key: WFLY-1351
>                 URL: https://issues.jboss.org/browse/WFLY-1351
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Dennis Reed
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha3
>
>
> org/jboss/as/clustering/impl/CoreGroupCommunicationService#handle catches and hides any internal exceptions, and just returns null instead.
> This breaks callers of CoreGroupCommunicationService when they get a null value where it's not expected (after verifying that the response was not flagged as an exception)
>     java.lang.NullPointerException
>         at org.jboss.as.clustering.lock.AbstractClusterLockSupport.lock(AbstractClusterLockSupport.java:157)
> It also catches an exception from the called method, and returns it as the return value, instead of just throwing it as an exception so it can be properly returned as an exception inside JGroups' RequestCorrelator.

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

From issues at jboss.org  Fri Jan  3 18:02:33 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 3 Jan 2014 18:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2704) FORM authentication
 credentials lost on failover
In-Reply-To: <JIRA.12528557.1388696632000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528557.1388696632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528557.1388696632000.29690.1388790153473@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro commented on WFLY-2704:
------------------------------------

It seems like this is most easily addressed by allowing replication of the user principal stored with the session.  Currently, Undertow's AuthenticatedSession is part of the local context of a session and is not replicated.
                
> FORM authentication credentials lost on failover
> ------------------------------------------------
>
>                 Key: WFLY-2704
>                 URL: https://issues.jboss.org/browse/WFLY-2704
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Final
>
>
> Unlike BASIC, DIGEST, and CERT authentication, FORM authentication requires an additional server side mechanism to store the credentials from the login form so that a user does not need to reauthenticate on failover.
> Traditionally, clustered SSO was the mechanism of choice (see https://issues.jboss.org/browse/JBAS-1900 )
> An analogous strategy is needed for 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 issues at jboss.org  Fri Jan  3 21:04:33 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Fri, 3 Jan 2014 21:04:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work
 with Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.29731.1388801073015@jira02.app.mwc.hst.phx2.redhat.com>


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

Ot?vio Garcia commented on WFLY-2690:
-------------------------------------

 Matus Zamborsky, I've tested with your commit from github, and works fine for me.
                
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Sat Jan  4 05:32:33 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Sat, 4 Jan 2014 05:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-393) Trait Hierarchy is not
 rebuilt correctly when merging packages
In-Reply-To: <JIRA.12528619.1388831451847@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528619.1388831451847@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528619.1388831451847.29760.1388831553195@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-393:
-------------------------------------

             Summary: Trait Hierarchy is not rebuilt correctly when merging packages
                 Key: DROOLS-393
                 URL: https://issues.jboss.org/browse/DROOLS-393
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final, 5.5.0.Final, 6.0.1.Final
            Reporter: Davide Sottara
            Assignee: Davide Sottara
            Priority: Critical
             Fix For: 5.5.1.Final, 6.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 issues at jboss.org  Sat Jan  4 08:19:32 2014
From: issues at jboss.org (Rich Midwinter (JIRA))
Date: Sat, 4 Jan 2014 08:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2708) Solr fails to deploy on CR1
In-Reply-To: <JIRA.12528620.1388841454077@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528620.1388841454077@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528620.1388841454077.29765.1388841572724@jira02.app.mwc.hst.phx2.redhat.com>

Rich Midwinter created WFLY-2708:
------------------------------------

             Summary: Solr fails to deploy on CR1
                 Key: WFLY-2708
                 URL: https://issues.jboss.org/browse/WFLY-2708
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Rich Midwinter


Solr (4.6) fails to deploy on CR1. I've had it working previously on Alpha builds and I gather it worked previously on Beta builds for someone else experiencing this issue - https://issues.apache.org/jira/browse/SOLR-5578


2014-01-04 12:59:34,138 WARN  [org.jboss.modules] (weld-worker-1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.solr.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/apache/hadoop/hdfs/web/re
sources/UserProvider (Module "deployment.solr.war:main" from Service Module Loader)
        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:428) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:106) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
        at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:94) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
        at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
        at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
        at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.NoClassDefFoundError: com/sun/jersey/spi/inject/InjectableProvider
        at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
        at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25]
        at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
        ... 20 more
Caused by: java.lang.ClassNotFoundException: com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
        ... 24 more

2014-01-04 12:59:34,148 INFO  [org.jboss.weld.Bootstrap] (weld-worker-1) WELD-000119: Not generating any bean definitions from org.apache.hadoop.hdfs.web.resources.UserProvider because of underlying class loading error: Type com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader] not found.  If this is unexpected, enable DEBUG logging to see the full error.
2014-01-04 12:59:34,893 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."solr.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."solr.war".WeldStartService: Failed to start service
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
  at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)

        at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:361)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
        at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
        at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
        at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
        at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
        ... 3 more

2014-01-04 12:59:34,901 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "solr.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"solr.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"solr.war\".WeldStartService: Failed to start 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 issues at jboss.org  Sat Jan  4 09:08:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sat, 4 Jan 2014 09:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.29769.1388844513305@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/4/14 9:07 AM:
--------------------------------------------------------

JGRP-1737 might alleviate the issue; need to re-test
                
      was (Author: belaban):
    JGRP-1737 might alleviate the issue
                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Sat Jan  4 10:44:33 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sat, 4 Jan 2014 10:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-100) JBossLogManagerLogger
 unconditionally does string conversion
In-Reply-To: <JIRA.12528621.1388850245930@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528621.1388850245930@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528621.1388850245930.29776.1388850273382@jira02.app.mwc.hst.phx2.redhat.com>

Philippe Marschall created JBLOGGING-100:
--------------------------------------------

             Summary: JBossLogManagerLogger unconditionally does string conversion
                 Key: JBLOGGING-100
                 URL: https://issues.jboss.org/browse/JBLOGGING-100
             Project: JBoss Logging
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: jboss-logging-logmanager
    Affects Versions: 3.1.3.GA
            Reporter: Philippe Marschall
            Assignee: James Perkins


{{JBossLogManagerLogger#doLog}} always converts the message to a String even if the level isn't loggable. This can have a negative performance impact and result in a lot of unnecessary allocations.

For example {{LogAuditProvider#audit}} does trace logging which ends up calling {{AuditEvent#toString}} even if trace logging isn't enabled. In our case this results in a lot of allocations outside of TLABs.

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

From issues at jboss.org  Sat Jan  4 14:52:33 2014
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 4 Jan 2014 14:52:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1950) Problems with connector 1.7
In-Reply-To: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499328.1377460254000.29786.1388865153166@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1950:
---------------------------------------

I don't see any progress.
To reproduce problems:
add
                <resource-adapter>
                    <archive>filesystem.rar</archive>
                    <transaction-support>NoTransaction</transaction-support>
                    <config-property name="Path">/</config-property>
                    <connection-definitions>
                        <connection-definition jndi-name="java:/Filesystem" class-name="biz.mbisoftware.fn.jca.filesystem.FilesystemManagedConnectionFactory"/>
                    </connection-definitions>
                </resource-adapter>
to standalone.xml.
Then remove 
<reauthentication-support>false</reauthentication-support>
from META-INF/ra.xml.
Then
04.01. 20:37:39,452 ERROR [org.jboss.msc.service.fail#failed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar": JBAS010446: Failed to start RA deployment [filesystem.rar]
        at org.jboss.as.connector.services.resourceadapters.deployment.AbstractResourceAdapterDeploymentService$1.run(AbstractResourceAdapterDeploymentService.java:281) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60-ea]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60-ea]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_60-ea]
        at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp/temp758703a19ace030c/filesystem.rar-b2b028622686a714/contents/
        at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2611) [ironjacamar-deployers-common-1.1.2.Final.jar:1.1.2.Final]
        at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:192) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:107) [wildfly-connector-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60-ea]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60-ea]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_60-ea]
Caused by: java.lang.NullPointerException
        at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182) [ironjacamar-common-impl-1.1.2.Final.jar:1.1.2.Final]
        at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2120) [ironjacamar-deployers-common-1.1.2.Final.jar:1.1.2.Final]
        ... 7 more
If you use filesystem-ra.xml.before as META-INF/ra.xml then you get irritating error:
04.01. 20:47:32,049 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar": org.jboss.msc.service.DuplicateServiceException: Service jboss.ra.filesystem is already registered
        at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:137)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60-ea]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60-ea]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_60-ea]
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.ra.filesystem is already registered
        at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:131)
        ... 5 more

                
> Problems with connector 1.7
> ---------------------------
>
>                 Key: WFLY-1950
>                 URL: https://issues.jboss.org/browse/WFLY-1950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Zhang
>         Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO  [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO  [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
>         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.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
>         ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
>         ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO  [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.

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

From issues at jboss.org  Sun Jan  5 09:10:32 2014
From: issues at jboss.org (Kenneth Jaeger (JIRA))
Date: Sun, 5 Jan 2014 09:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2684) Security Domains not
 accessible throught web console
In-Reply-To: <JIRA.12528395.1387836905000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528395.1387836905000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528395.1387836905000.29802.1388931032932@jira02.app.mwc.hst.phx2.redhat.com>


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

Kenneth Jaeger commented on WFLY-2684:
--------------------------------------

I can confirm I am seeing this same behavior on Wildfly 8.0.0 CR1 running on Windows 7 SP using the following Java version:
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b121)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63, mixed mode)
                
> Security Domains not accessible throught web console
> ----------------------------------------------------
>
>                 Key: WFLY-2684
>                 URL: https://issues.jboss.org/browse/WFLY-2684
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux 2.6.32-358.23.2.el6.x86_64 (CentOS 6.4) with 1.7.0_45-mockbuild_2013_10_23_08_18-b00 (OpenJDK  7) or Windows 7 64bit with Oracle Java 7
>            Reporter: Marko Mrvelj
>            Assignee: Heiko Braun
>
> When trying to access Security Domains under Profile/Security tree, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
> Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
> On the same (Linux) machine this works in 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 issues at jboss.org  Sun Jan  5 10:35:34 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 5 Jan 2014 10:35:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2709) Connector Subsystem is
 Missing connection-definitions.clear-statistics resource key
In-Reply-To: <JIRA.12528624.1388936027477@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528624.1388936027477@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528624.1388936027477.29805.1388936134625@jira02.app.mwc.hst.phx2.redhat.com>

Philippe Marschall created WFLY-2709:
----------------------------------------

             Summary: Connector Subsystem is Missing connection-definitions.clear-statistics resource key
                 Key: WFLY-2709
                 URL: https://issues.jboss.org/browse/WFLY-2709
             Project: WildFly
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.CR1
            Reporter: Philippe Marschall
            Assignee: Jesper Pedersen


The connector subsystem is missing the resource key: {{?connection-definitions.clear-statistics?}}. This results in the following exception when looking at the connection definitions of a resource adapter in VisualVM:

{code}
16:06:10,884 ERROR [org.jboss.as.controller.management-operation] (RMI TCP Connection(2)-192.168.0.21) JBAS014612: Operation ("read-resource-description") failed - address: ([
    ("deployment" => "XADisk.rar"),
    ("subsystem" => "resource-adapters"),
    ("statistics" => "statistics"),
    ("resource-adapter" => "XADisk.rar"),
    ("connection-definitions" => "java:global/XADiskCF")
]): java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key connection-definitions.clear-statistics
	at java.util.ResourceBundle.getObject(ResourceBundle.java:450) [rt.jar:1.8.0-ea]
	at java.util.ResourceBundle.getString(ResourceBundle.java:407) [rt.jar:1.8.0-ea]
	at org.jboss.as.controller.descriptions.StandardResourceDescriptionResolver.getOperationDescription(StandardResourceDescriptionResolver.java:184)
	at org.jboss.as.controller.descriptions.DefaultOperationDescriptionProvider.getModelDescription(DefaultOperationDescriptionProvider.java:157)
	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecuteInternal(ReadResourceDescriptionHandler.java:213)
	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecute(ReadResourceDescriptionHandler.java:157)
	at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.execute(ReadResourceDescriptionHandler.java:150)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146)
	at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85)
	at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccessWithInstanceNotFoundExceptionIfNotAccessible(ResourceAccessControlUtil.java:70)
	at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanInfo(ModelControllerMBeanHelper.java:199)
	at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanInfo(ModelControllerMBeanServerPlugin.java:131)
	at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:582)
	at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:570)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1460) [rt.jar:1.8.0-ea]
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) [rt.jar:1.8.0-ea]
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307) [rt.jar:1.8.0-ea]
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399) [rt.jar:1.8.0-ea]
	at javax.management.remote.rmi.RMIConnectionImpl.getMBeanInfo(RMIConnectionImpl.java:904) [rt.jar:1.8.0-ea]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0-ea]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0-ea]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0-ea]
	at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0-ea]
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323) [rt.jar:1.8.0-ea]
	at sun.rmi.transport.Transport$1.run(Transport.java:178) [rt.jar:1.8.0-ea]
	at sun.rmi.transport.Transport$1.run(Transport.java:175) [rt.jar:1.8.0-ea]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
	at sun.rmi.transport.Transport.serviceCall(Transport.java:174) [rt.jar:1.8.0-ea]
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:557) [rt.jar:1.8.0-ea]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:812) [rt.jar:1.8.0-ea]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:671) [rt.jar:1.8.0-ea]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-ea]
{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 issues at jboss.org  Sun Jan  5 11:49:32 2014
From: issues at jboss.org (Kenneth Jaeger (JIRA))
Date: Sun, 5 Jan 2014 11:49:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2684) Security Domains not
 accessible throught web console
In-Reply-To: <JIRA.12528395.1387836905000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528395.1387836905000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528395.1387836905000.29809.1388940572889@jira02.app.mwc.hst.phx2.redhat.com>


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

Kenneth Jaeger edited comment on WFLY-2684 at 1/5/14 11:48 AM:
---------------------------------------------------------------

I can confirm I am seeing this same behavior on Wildfly 8.0.0 CR1 running on Windows 7 SP1 using the following Java version:
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b121)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63, mixed mode)
                
      was (Author: kjjaeger):
    I can confirm I am seeing this same behavior on Wildfly 8.0.0 CR1 running on Windows 7 SP using the following Java version:
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b121)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63, mixed mode)
                  
> Security Domains not accessible throught web console
> ----------------------------------------------------
>
>                 Key: WFLY-2684
>                 URL: https://issues.jboss.org/browse/WFLY-2684
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux 2.6.32-358.23.2.el6.x86_64 (CentOS 6.4) with 1.7.0_45-mockbuild_2013_10_23_08_18-b00 (OpenJDK  7) or Windows 7 64bit with Oracle Java 7
>            Reporter: Marko Mrvelj
>            Assignee: Heiko Braun
>
> When trying to access Security Domains under Profile/Security tree, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
> Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
> On the same (Linux) machine this works in 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 issues at jboss.org  Sun Jan  5 23:13:32 2014
From: issues at jboss.org (Jeff Zhang (JIRA))
Date: Sun, 5 Jan 2014 23:13:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1129) update docant to 1.1.2 using
 xerces 2.11.0
In-Reply-To: <JIRA.12528140.1387371891000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528140.1387371891000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528140.1387371891000.29943.1388981612770@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang resolved JBJCA-1129.
-------------------------------

    Resolution: Done


https://github.com/ironjacamar/ironjacamar/commit/83b7326ccf8b00ebdf114b7b815d71efa5d9d38f
                
> update docant to 1.1.2 using xerces 2.11.0
> ------------------------------------------
>
>                 Key: JBJCA-1129
>                 URL: https://issues.jboss.org/browse/JBJCA-1129
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Documentation
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>


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

From issues at jboss.org  Sun Jan  5 23:15:33 2014
From: issues at jboss.org (Jeff Zhang (JIRA))
Date: Sun, 5 Jan 2014 23:15:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1132) fix NPE of
 reauthenticationSupport in OutboundResourceAdapterImpl
In-Reply-To: <JIRA.12528629.1388981720348@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528629.1388981720348@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528629.1388981720348.29946.1388981733446@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Zhang created JBJCA-1132:
---------------------------------

             Summary: fix NPE of reauthenticationSupport in OutboundResourceAdapterImpl
                 Key: JBJCA-1132
                 URL: https://issues.jboss.org/browse/JBJCA-1132
             Project: IronJacamar
          Issue Type: Bug
          Components: Common
    Affects Versions: 1.1.2.Final
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.1.3.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 issues at jboss.org  Sun Jan  5 23:17:32 2014
From: issues at jboss.org (Jeff Zhang (JIRA))
Date: Sun, 5 Jan 2014 23:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1950) Problems with connector 1.7
In-Reply-To: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499328.1377460254000.29950.1388981852747@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang commented on WFLY-1950:
----------------------------------

Thanks Frank, we will fix it. Track it https://issues.jboss.org/browse/JBJCA-1132
                
> Problems with connector 1.7
> ---------------------------
>
>                 Key: WFLY-1950
>                 URL: https://issues.jboss.org/browse/WFLY-1950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Zhang
>         Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO  [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO  [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
>         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.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
>         ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
>         ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO  [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.

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

From issues at jboss.org  Sun Jan  5 23:43:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 5 Jan 2014 23:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.29960.1388983413037@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1047515|https://bugzilla.redhat.com/show_bug.cgi?id=1047515] from NEW to POST
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Mon Jan  6 05:11:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 6 Jan 2014 05:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.30121.1389003092967@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1717:
--------------------------------

Tested perf with UnicastTest (measures throughput *not* latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 2 nodes: sender on cluster01 and receiver on cluster02
- fast.xml with ip_ttl=1
-- ignore_dont_bundle=true (default)
- Sending 100'000 1K messages

Perf was measured with bundler_type
* {{sender-sends-with-timer}} (SSWT)
* {{transfer-queue}} (TQ)
* {{sender-sends}} (SS)
* Using {{DONT_BUNDLE}} (+B) or off (-B)


|| sender threads || SSWT (-B) || SSWT (+B) || TQ (-B) || TQ (+B) || SS (-B) || SS (+B) ||
|   1 |  70 | 120 | 120 | 120 |  73 |  73 |
|   4 | 77 |  112 | 120 | 120 | 120 | 120 |
| 10 | 75 | 108 | 120 | 120 | 120 | 120 |
| 25 | 75 | 100 | 120 | 120 | 120 | 120 |
                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Mon Jan  6 05:17:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 6 Jan 2014 05:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.30126.1389003452809@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1717:
--------------------------------

Comments:
* DONT_BUNDLE is ignored when sending a message *except for SSWT*
** That's why SSWT -B is slow: messages are not bundled
* SSWT had quite a high variation between runs
* SS is slow with only 1 sender thread
** With 2 threads SS (-B/+B) achived ~ 118

                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Mon Jan  6 05:19:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 6 Jan 2014 05:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.30129.1389003572753@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/6/14 5:17 AM:
--------------------------------------------------------

Tested perf with UnicastTest (measures throughput *not* latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 2 nodes: sender on cluster01 and receiver on cluster02
- fast.xml with ip_ttl=1
-- ignore_dont_bundle=true (default)
- Sending 100'000 1K messages

Perf was measured with bundler_type
* {{sender-sends-with-timer}} (SSWT)
* {{transfer-queue}} (TQ)
* {{sender-sends}} (SS)
* Using {{DONT_BUNDLE}} (+B) or off (-B)

The results are (in 1000 msgs/sec):

|| sender threads || SSWT (-B) || SSWT (+B) || TQ (-B) || TQ (+B) || SS (-B) || SS (+B) ||
|   1 |  70 | 120 | 120 | 120 |  73 |  73 |
|   4 | 77 |  112 | 120 | 120 | 120 | 120 |
| 10 | 75 | 108 | 120 | 120 | 120 | 120 |
| 25 | 75 | 100 | 120 | 120 | 120 | 120 |
                
      was (Author: belaban):
    Tested perf with UnicastTest (measures throughput *not* latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 2 nodes: sender on cluster01 and receiver on cluster02
- fast.xml with ip_ttl=1
-- ignore_dont_bundle=true (default)
- Sending 100'000 1K messages

Perf was measured with bundler_type
* {{sender-sends-with-timer}} (SSWT)
* {{transfer-queue}} (TQ)
* {{sender-sends}} (SS)
* Using {{DONT_BUNDLE}} (+B) or off (-B)


|| sender threads || SSWT (-B) || SSWT (+B) || TQ (-B) || TQ (+B) || SS (-B) || SS (+B) ||
|   1 |  70 | 120 | 120 | 120 |  73 |  73 |
|   4 | 77 |  112 | 120 | 120 | 120 | 120 |
| 10 | 75 | 108 | 120 | 120 | 120 | 120 |
| 25 | 75 | 100 | 120 | 120 | 120 | 120 |
                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Mon Jan  6 05:21:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 6 Jan 2014 05:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.30133.1389003692789@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/6/14 5:19 AM:
--------------------------------------------------------

Comments:
* DONT_BUNDLE is ignored when sending a message *except for SSWT*
** That's why SSWT -B is slow: messages are not bundled
* SSWT had quite a high variation between runs
* SS is slow with only 1 sender thread
** With 2 threads SS (-B/+B) achived ~ 118
* TQ achieved the highest perf regardless of the number of senders. Note that 120'000 msgs/sec ~= 120MB/sec, that's close to the max throughput of 1Gbps ethernet of 125MB/sec
                
      was (Author: belaban):
    Comments:
* DONT_BUNDLE is ignored when sending a message *except for SSWT*
** That's why SSWT -B is slow: messages are not bundled
* SSWT had quite a high variation between runs
* SS is slow with only 1 sender thread
** With 2 threads SS (-B/+B) achived ~ 118

                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Mon Jan  6 05:33:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 6 Jan 2014 05:33:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-346) Phreak broke the Audit View
In-Reply-To: <JIRA.12525636.1384889307000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525636.1384889307000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525636.1384889307000.30173.1389004412726@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1032252|https://bugzilla.redhat.com/show_bug.cgi?id=1032252] from ON_QA to VERIFIED
                
> Phreak broke the Audit View
> ---------------------------
>
>                 Key: DROOLS-346
>                 URL: https://issues.jboss.org/browse/DROOLS-346
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.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 issues at jboss.org  Mon Jan  6 06:07:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Jan 2014 06:07:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2456) Using add-user.bat for
 initial admin user results in "JBAS015234: No mgmt-groups.properties files
 found"
In-Reply-To: <JIRA.12518197.1383793123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518197.1383793123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518197.1383793123000.30256.1389006454183@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-2456:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2456
>                 URL: https://issues.jboss.org/browse/WFLY-2456
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7, 32-bit, jdk1.7.0_45
>            Reporter: John Lusk
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Just getting started w/Wildfly after a long absence from Java.  Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
>  a) Management User (mgmt-users.properties)
>  b) Application User (application-users.properties)
> (a): a
>  * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>

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

From issues at jboss.org  Mon Jan  6 07:03:33 2014
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Mon, 6 Jan 2014 07:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-287) Websocket application working
 with multiple clients (e.g. chat style applications) fails due
 NullPointerException
In-Reply-To: <JIRA.12528639.1389009796293@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528639.1389009796293@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528639.1389009796293.30363.1389009813490@jira02.app.mwc.hst.phx2.redhat.com>

Radim Hatlapatka created JBWEB-287:
--------------------------------------

             Summary: Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
                 Key: JBWEB-287
                 URL: https://issues.jboss.org/browse/JBWEB-287
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Core
            Reporter: Radim Hatlapatka
            Assignee: Remy Maucherat
            Priority: Critical


When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:

{noformat}
11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{noformat}

The same application correctly works with Tomcat 7

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

From issues at jboss.org  Mon Jan  6 07:05:32 2014
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Mon, 6 Jan 2014 07:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-287) Websocket application working
 with multiple clients (e.g. chat style applications) fails due
 NullPointerException
In-Reply-To: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528639.1389009796000.30370.1389009932902@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hatlapatka updated JBWEB-287:
-----------------------------------

    Attachment: byteslounge.war


The test websocket app
                
> Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-287
>                 URL: https://issues.jboss.org/browse/JBWEB-287
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>            Reporter: Radim Hatlapatka
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: byteslounge.war
>
>
> When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
> {noformat}
> 11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
> 	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> The same application correctly works with Tomcat 7

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

From issues at jboss.org  Mon Jan  6 07:09:33 2014
From: issues at jboss.org (David Hladky (JIRA))
Date: Mon, 6 Jan 2014 07:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2199) There is AS7 instead of
 Wildfly on Projects page
In-Reply-To: <JIRA.12501977.1380702880000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501977.1380702880000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501977.1380702880000.30381.1389010173300@jira02.app.mwc.hst.phx2.redhat.com>


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

David Hladky commented on WFLY-2199:
------------------------------------

We still do not have WildFly on the projects page. Any progress on this?
                
> There is AS7 instead of Wildfly on Projects page
> ------------------------------------------------
>
>                 Key: WFLY-2199
>                 URL: https://issues.jboss.org/browse/WFLY-2199
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: David Hladky
>            Assignee: Jason Greene
>         Attachments: project-site.zip
>
>
> Hi, in order to fix ORG-1814 I need the Wildfly web pages author to fill project properties file and tell me his URL, so I can add it to the web page. 
> More information (including example) can be found here: https://www.jboss.org/help/awestructguide (the last chapter).
> Make sure it is a property file and not a link to a property file, that is in i-frame. 

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

From issues at jboss.org  Mon Jan  6 07:19:32 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 6 Jan 2014 07:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2611) Support CDI injection in
 various JSF artifacts
In-Reply-To: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527051.1386241760000.30395.1389010772851@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomas Remes updated WFLY-2611:
------------------------------

    Component/s: JSF

    
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
>                 Key: WFLY-2611
>                 URL: https://issues.jboss.org/browse/WFLY-2611
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec). 
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver|works|
> |javax.faces.application.ApplicationFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.NavigationHandler|works|
> |javax.faces.application.ResourceHandler|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
> |javax.faces.component.visit.VisitContextFactory|works|
> |javax.faces.context.ExceptionHandlerFactory|works|
> |javax.faces.context.ExternalContextFactory|works|
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.FlashFactory|works|
> |javax.faces.context.PartialViewContextFactory|works|
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.ClientWindowFactory|works|
> |javax.faces.lifecycle.LifecycleFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.ViewDeclarationLanguageFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.FaceletCacheFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.TagHandlerDelegateFactory|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 issues at jboss.org  Mon Jan  6 07:25:32 2014
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Mon, 6 Jan 2014 07:25:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-287) Websocket application working
 with multiple clients (e.g. chat style applications) fails due
 NullPointerException
In-Reply-To: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528639.1389009796000.30407.1389011132720@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hatlapatka edited comment on JBWEB-287 at 1/6/14 7:23 AM:
----------------------------------------------------------------

The test websocket app

It is based on [http://www.byteslounge.com/tutorials/java-ee-html5-websockets-with-multiple-clients-example] with added "descriptor" jar as lib for enabling websocket functionality [enable-websockets.jar|http://anonsvn.jboss.org/repos/jbossweb/branches/7.4.x/res/enable-websockets.jar].
                
      was (Author: rhatlapa):
    The test websocket app
                  
> Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-287
>                 URL: https://issues.jboss.org/browse/JBWEB-287
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>            Reporter: Radim Hatlapatka
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: byteslounge.war
>
>
> When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
> {noformat}
> 11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
> 	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> The same application correctly works with Tomcat 7

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

From issues at jboss.org  Mon Jan  6 07:27:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 6 Jan 2014 07:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2646) Expose patch description
	through mgmt API
In-Reply-To: <JIRA.12527845.1386869349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527845.1386869349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527845.1386869349000.30415.1389011253119@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2646:
------------------------------------------

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

    
> Expose patch description through mgmt API
> -----------------------------------------
>
>                 Key: WFLY-2646
>                 URL: https://issues.jboss.org/browse/WFLY-2646
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> It should be possible to view the description of an installed patch through the mgmt API (maybe patch history). The information is stored as part of the backed up patch.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 issues at jboss.org  Mon Jan  6 07:37:33 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 6 Jan 2014 07:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2611) Support CDI injection in
 various JSF artifacts
In-Reply-To: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527051.1386241760000.30424.1389011853299@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomas Remes commented on WFLY-2611:
-----------------------------------

In JSF spec there is also following sentence: "..the following JSF artifacts are also injectable."  followed by the classes listed above. I am not sure, if I understand it correctly. Does it mean that when I create e.g my custom NavigationHandler (and specify it in faces-config), should it be available for injection? e.g like this:

{noformat}
@Inject
CustomNavigationHandler handler;
{noformat}

[~ssilvert] Can you please elaborate? 
                
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
>                 Key: WFLY-2611
>                 URL: https://issues.jboss.org/browse/WFLY-2611
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec). 
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver|works|
> |javax.faces.application.ApplicationFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.NavigationHandler|works|
> |javax.faces.application.ResourceHandler|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
> |javax.faces.component.visit.VisitContextFactory|works|
> |javax.faces.context.ExceptionHandlerFactory|works|
> |javax.faces.context.ExternalContextFactory|works|
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.FlashFactory|works|
> |javax.faces.context.PartialViewContextFactory|works|
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.ClientWindowFactory|works|
> |javax.faces.lifecycle.LifecycleFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.ViewDeclarationLanguageFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.FaceletCacheFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.TagHandlerDelegateFactory|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 issues at jboss.org  Mon Jan  6 07:43:32 2014
From: issues at jboss.org (Martin Simka (JIRA))
Date: Mon, 6 Jan 2014 07:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2710) way (new command,
 extension of existing command) to display information about patch
 file
In-Reply-To: <JIRA.12528644.1389012176374@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528644.1389012176374@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528644.1389012176374.30445.1389012212806@jira02.app.mwc.hst.phx2.redhat.com>

Martin Simka created WFLY-2710:
----------------------------------

             Summary: way (new command, extension of existing command) to display information about patch file
                 Key: WFLY-2710
                 URL: https://issues.jboss.org/browse/WFLY-2710
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Patching
    Affects Versions: 8.0.0.CR1
            Reporter: Martin Simka
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.Final


It should be possible to view details (description, target version ... ) of a patch file. There is no other way to display this information except unziping patch file and opening patch.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 issues at jboss.org  Mon Jan  6 07:47:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 6 Jan 2014 07:47:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2710) way (new command,
 extension of existing command) to display information about patch
 file
In-Reply-To: <JIRA.12528644.1389012176000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528644.1389012176000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528644.1389012176000.30451.1389012455614@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2710:
------------------------------------------

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

    
> way (new command, extension of existing command) to display information about patch file
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2710
>                 URL: https://issues.jboss.org/browse/WFLY-2710
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> It should be possible to view details (description, target version ... ) of a patch file. There is no other way to display this information except unziping patch file and opening patch.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 issues at jboss.org  Mon Jan  6 07:57:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 6 Jan 2014 07:57:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2199) There is AS7 instead of
 Wildfly on Projects page
In-Reply-To: <JIRA.12501977.1380702880000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501977.1380702880000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501977.1380702880000.30468.1389013052724@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-2199:
-----------------------------------

This was taken care of when we updated web site about a month ago.

http://www.wildfly.org/project.properties
                
> There is AS7 instead of Wildfly on Projects page
> ------------------------------------------------
>
>                 Key: WFLY-2199
>                 URL: https://issues.jboss.org/browse/WFLY-2199
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: David Hladky
>            Assignee: Jason Greene
>         Attachments: project-site.zip
>
>
> Hi, in order to fix ORG-1814 I need the Wildfly web pages author to fill project properties file and tell me his URL, so I can add it to the web page. 
> More information (including example) can be found here: https://www.jboss.org/help/awestructguide (the last chapter).
> Make sure it is a property file and not a link to a property file, that is in i-frame. 

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

From issues at jboss.org  Mon Jan  6 08:15:34 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 6 Jan 2014 08:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags doesn't work
 with Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.30534.1389014134415@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2690:
---------------------------------------

The proposed commit breaks the Identifier contract. We'll have to use a different solution.
                
> JSP/JSPX tags doesn't work with Wildfly CR1
> -------------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Mon Jan  6 08:43:32 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 6 Jan 2014 08:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1758)
 UnknownFormatConversionException in UNICAST3 logging
In-Reply-To: <JIRA.12528269.1387482073000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528269.1387482073000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528269.1387482073000.30591.1389015812950@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro commented on JGRP-1758:
------------------------------------

You're right.  Sorry about that.
                
> UnknownFormatConversionException in UNICAST3 logging
> ----------------------------------------------------
>
>                 Key: JGRP-1758
>                 URL: https://issues.jboss.org/browse/JGRP-1758
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4.1
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 3.4.2, 3.5
>
>
> When UNICAST3 tries to log a "FailedToDeliverMsg", it translates to the following pattern from jg-messages.properties:
> "JGRP000039: %s: failed to deliver %s %s: %t"
> This causes the following exception (because %t is not a valid conversion token):
> {noformat}
> java.util.UnknownFormatConversionException: Conversion = 't'
>     at java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2690)
>     at java.util.Formatter.parse(Formatter.java:2528)
>     at java.util.Formatter.format(Formatter.java:2469)
>     at java.util.Formatter.format(Formatter.java:2423)
>     at java.lang.String.format(String.java:2797)
>     at org.jboss.logmanager.ExtLogRecord.formatRecord(ExtLogRecord.java:434)
>     at org.jboss.logmanager.ExtLogRecord.getFormattedMessage(ExtLogRecord.java:397)
>     at org.jboss.logmanager.formatters.Formatters$10.renderRaw(Formatters.java:568)
>     at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:225)
>     at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86)
>     at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35)
>     at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49)
>     at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:79)
>     at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:296)
>     at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
>     at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
>     at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
>     at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:304)
>     at org.jboss.logmanager.Logger.logRaw(Logger.java:721)
>     at org.jboss.logmanager.Logger.log(Logger.java:672)
>     at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50)
>     at org.jboss.logging.Logger.errorf(Logger.java:1369)
>     at org.jboss.as.clustering.jgroups.LogFactory$LogAdapter.error(LogFactory.java:104)
>     at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:697)
>     at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
>     at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
>     at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
>     at org.jgroups.protocols.FD.up(FD.java:255)
>     at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
>     at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
>     at org.jgroups.protocols.Discovery.up(Discovery.java:379)
>     at org.jgroups.protocols.MPING.up(MPING.java:181)
>     at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2609)
>     at org.jgroups.protocols.TP.passMessageUp(TP.java:1399)
>     at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585)
>     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:724)
> {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 issues at jboss.org  Mon Jan  6 08:57:33 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 6 Jan 2014 08:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2711) Upgrade JGroups to 3.4.2.Final
In-Reply-To: <JIRA.12528661.1389016591449@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528661.1389016591449@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528661.1389016591449.30635.1389016653110@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2711:
----------------------------------

             Summary: Upgrade JGroups to 3.4.2.Final
                 Key: WFLY-2711
                 URL: https://issues.jboss.org/browse/WFLY-2711
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.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 issues at jboss.org  Mon Jan  6 09:21:32 2014
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Mon, 6 Jan 2014 09:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2712) Possible NPE in
 RemoteDeployer from WS tests-integration
In-Reply-To: <JIRA.12528666.1389018040111@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528666.1389018040111@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528666.1389018040111.30718.1389018092961@jira02.app.mwc.hst.phx2.redhat.com>

Rostislav Svoboda created WFLY-2712:
---------------------------------------

             Summary: Possible NPE in RemoteDeployer from WS tests-integration
                 Key: WFLY-2712
                 URL: https://issues.jboss.org/browse/WFLY-2712
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Rostislav Svoboda
            Assignee: Alessio Soldano


https://github.com/rsvoboda/wildfly/blob/master/webservices/tests-integration/src/main/java/org/jboss/as/webservices/deployer/RemoteDeployer.java#L305  
Possible NPE, check 'if (options != null)' is present only on line 284.

Or is it intentional to throw exception ?



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

From issues at jboss.org  Mon Jan  6 09:55:33 2014
From: issues at jboss.org (John Doyle (JIRA))
Date: Mon, 6 Jan 2014 09:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2710) way (new command,
 extension of existing command) to display information about patch
 file
In-Reply-To: <JIRA.12528644.1389012176000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528644.1389012176000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528644.1389012176000.30813.1389020133273@jira02.app.mwc.hst.phx2.redhat.com>


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

John Doyle commented on WFLY-2710:
----------------------------------

The idea being that from the CLI you could point to an uninstalled patch on the filesystem and read its metadata?
                
> way (new command, extension of existing command) to display information about patch file
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2710
>                 URL: https://issues.jboss.org/browse/WFLY-2710
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> It should be possible to view details (description, target version ... ) of a patch file. There is no other way to display this information except unziping patch file and opening patch.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 issues at jboss.org  Mon Jan  6 10:05:33 2014
From: issues at jboss.org (Martin Simka (JIRA))
Date: Mon, 6 Jan 2014 10:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2710) way (new command,
 extension of existing command) to display information about patch
 file
In-Reply-To: <JIRA.12528644.1389012176000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528644.1389012176000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528644.1389012176000.30871.1389020733425@jira02.app.mwc.hst.phx2.redhat.com>


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

Martin Simka commented on WFLY-2710:
------------------------------------

Yes, that is exactly what I mean.
                
> way (new command, extension of existing command) to display information about patch file
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2710
>                 URL: https://issues.jboss.org/browse/WFLY-2710
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> It should be possible to view details (description, target version ... ) of a patch file. There is no other way to display this information except unziping patch file and opening patch.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 issues at jboss.org  Mon Jan  6 10:47:32 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jan 2014 10:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1950) Problems with connector 1.7
In-Reply-To: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499328.1377460254000.31048.1389023252840@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on WFLY-1950:
---------------------------------------

 <reauthentication-support> is mandatory
                
> Problems with connector 1.7
> ---------------------------
>
>                 Key: WFLY-1950
>                 URL: https://issues.jboss.org/browse/WFLY-1950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Zhang
>         Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO  [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO  [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
>         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.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
>         ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
>         ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO  [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.

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

From issues at jboss.org  Mon Jan  6 11:01:35 2014
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Mon, 6 Jan 2014 11:01:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1950) Problems with connector 1.7
In-Reply-To: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499328.1377460254000.31103.1389024095556@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1950:
---------------------------------------

This is still wrong i my opinion / from my understanding.
Looking at http://xmlns.jcp.org/xml/ns/javaee/connector_1_7.xsd I see:
	<complexType name="outbound-resourceadapterType">
		<annotation>
			<documentation>
...
        If there is no reauthentication-support specified as part of
        this element or metadata annotation, then the application server must consider 
        that the resource adapter does not support re-authentication of 
        ManagedConnections.
			<element name="reauthentication-support" type="javaee:true-falseType" minOccurs="0">
So it's not a mandatory element and default value has to false when not given.

Anyways, required or not, a NPE should not happen at all.
                
> Problems with connector 1.7
> ---------------------------
>
>                 Key: WFLY-1950
>                 URL: https://issues.jboss.org/browse/WFLY-1950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Zhang
>         Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO  [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO  [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
>         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.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
>         ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
>         ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO  [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.

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

From issues at jboss.org  Mon Jan  6 11:13:33 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 6 Jan 2014 11:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-61) timeout handling waiting for
	future
In-Reply-To: <JIRA.12477184.1350417759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477184.1350417759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477184.1350417759000.31136.1389024813477@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved WFLY-61.
-----------------------------------

    Resolution: Out of Date


Confirming it's out of date.
                
> timeout handling waiting for future
> -----------------------------------
>
>                 Key: WFLY-61
>                 URL: https://issues.jboss.org/browse/WFLY-61
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final, 8.0.0.CR1
>
>
> The issue was reported in AS7-5350 which points to a CLI testcase that fails on windows.
> The test starts a CLI process and deliberately specifies a wrong port for the controller expecting a failure during connection. The CLI sends a read-attribute operation request on connect to make sure the connection is working. The test is waiting for a response from the controller for 10 sec and then times out. The time out of the ModelControllerClient is 5 sec. The test still fails after 10 sec time out but the error output stream of the CLI process does contain the stack trace of the expected exception, i.e. that the controller was not available at the specified address.
> When the testcase times out, it destroys the CLI process, perhaps, this triggers some actions and the exception is finally thrown and the stack trace gets logged but it's too late.

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

From issues at jboss.org  Mon Jan  6 11:33:33 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Mon, 6 Jan 2014 11:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.31217.1389026013063@jira02.app.mwc.hst.phx2.redhat.com>


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

Pavol Pitonak moved RF-13460 to WFLY-2713:
------------------------------------------

              Project: WildFly  (was: RichFaces)
                  Key: WFLY-2713  (was: RF-13460)
    Affects Version/s: 8.0.0.CR1
                           (was: 5.0.0.Alpha2)
          Component/s: JSF
                           (was: component-a4j-core)
                           (was: regression)

    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
> RichFaces 5.0.0.Alpha2
>            Reporter: Pavol Pitonak
>            Priority: Blocker
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, nothing happens in browser
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Mon Jan  6 11:33:33 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Mon, 6 Jan 2014 11:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.31230.1389026013573@jira02.app.mwc.hst.phx2.redhat.com>


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

Pavol Pitonak updated WFLY-2713:
--------------------------------

    Priority: Major  (was: Blocker)

    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
> RichFaces 5.0.0.Alpha2
>            Reporter: Pavol Pitonak
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, nothing happens in browser
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Mon Jan  6 11:33:33 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Mon, 6 Jan 2014 11:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.31233.1389026013733@jira02.app.mwc.hst.phx2.redhat.com>


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

Pavol Pitonak updated WFLY-2713:
--------------------------------

    Attachment:     (was: reproducer.zip)

    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
> RichFaces 5.0.0.Alpha2
>            Reporter: Pavol Pitonak
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, nothing happens in browser
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Mon Jan  6 11:33:33 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Mon, 6 Jan 2014 11:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.31238.1389026013981@jira02.app.mwc.hst.phx2.redhat.com>


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

Pavol Pitonak updated WFLY-2713:
--------------------------------

    Attachment: reproducer.zip

    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
> RichFaces 5.0.0.Alpha2
>            Reporter: Pavol Pitonak
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, nothing happens in browser
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Mon Jan  6 11:33:34 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Mon, 6 Jan 2014 11:33:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.31244.1389026014377@jira02.app.mwc.hst.phx2.redhat.com>


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

Pavol Pitonak updated WFLY-2713:
--------------------------------

    Description: 
# unzip attached reproducer
# mvn clean package
# deploy reproducer.war to WildFly 
# open http://localhost:8080/reproducer/
# type something to the input

result:
* in Chrome, a popup with error is displayed
* server console contains stack trace:
{code}
17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
{code}
* works fine in Firefox 26
* works fine in WildFly 8.0.0.Beta1

  was:
# unzip attached reproducer
# mvn clean package
# deploy reproducer.war to WildFly 
# open http://localhost:8080/reproducer/
# type something to the input

result:
* in Chrome, nothing happens in browser
* server console contains stack trace:
{code}
17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
{code}
* works fine in Firefox 26
* works fine in WildFly 8.0.0.Beta1


    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Mon Jan  6 11:33:34 2014
From: issues at jboss.org (Pavol Pitonak (JIRA))
Date: Mon, 6 Jan 2014 11:33:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.31242.1389026014292@jira02.app.mwc.hst.phx2.redhat.com>


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

Pavol Pitonak updated WFLY-2713:
--------------------------------

    Environment: 
WildFly 8.0.0.CR1
Chrome 31.0.1650.63 @ Fedora 20 x86_64


  was:
WildFly 8.0.0.CR1
Chrome 31.0.1650.63 @ Fedora 20 x86_64
RichFaces 5.0.0.Alpha2


    
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, nothing happens in browser
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Mon Jan  6 11:35:33 2014
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Mon, 6 Jan 2014 11:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2663) mod_cluster metric properties
 are never applied
In-Reply-To: <JIRA.12528097.1387305213000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528097.1387305213000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528097.1387305213000.31249.1389026133277@jira02.app.mwc.hst.phx2.redhat.com>


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

Jean-Frederic Clere commented on WFLY-2663:
-------------------------------------------

See https://github.com/wildfly/wildfly/pull/5626
                
> mod_cluster metric properties are never applied
> -----------------------------------------------
>
>                 Key: WFLY-2663
>                 URL: https://issues.jboss.org/browse/WFLY-2663
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Are parsed for but never applied.
> {noformat}
>  <load-metric type="busyness">
>                 <property name="foo" value="bar"/>
>             </load-metric>
> {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 issues at jboss.org  Mon Jan  6 11:49:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 6 Jan 2014 11:49:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2571) Make
 wildfly-mod_cluster-undertow module a separate subsystem
In-Reply-To: <JIRA.12526089.1385405804000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526089.1385405804000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526089.1385405804000.31287.1389026972715@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar closed WFLY-2571.
--------------------------------

    Resolution: Rejected

    
> Make wildfly-mod_cluster-undertow module a separate subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-2571
>                 URL: https://issues.jboss.org/browse/WFLY-2571
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.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 issues at jboss.org  Mon Jan  6 12:43:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 6 Jan 2014 12:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-367) Kie-ci doesn't try to access
 additional remote repositories declared in settings.xml
In-Reply-To: <JIRA.12527211.1386328527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527211.1386328527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527211.1386328527000.31383.1389030213575@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1039016|https://bugzilla.redhat.com/show_bug.cgi?id=1039016] from ON_QA to VERIFIED
                
> Kie-ci doesn't try to access additional remote repositories declared in settings.xml
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-367
>                 URL: https://issues.jboss.org/browse/DROOLS-367
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> In maven's settings.xml file it is possible to create additional profiles and declare additional remote repositories as in:
> {code}
>   <profiles>
>     <profile>
>       <id>guvnor-m2-profile</id>
>       <activation>
>         <activeByDefault>true</activeByDefault>
>       </activation>
>       <repositories>
>         <repository>
>           <id>guvnor-m2-repo</id>
>           <name>Guvnor M2 Repo</name>
>           <url>http://localhost:8080/m-kie-drools-wb-distribution-wars-6.0.0.Final-jboss-as7.0/maven2</url>
>         </repository>
>       </repositories>
>     </profile>
>   </profiles>
> {code}
> However kie-ci doesn't try to access this further repositories (as it should) when resolving a kjar.

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

From issues at jboss.org  Mon Jan  6 13:09:32 2014
From: issues at jboss.org (Remy Maucherat (JIRA))
Date: Mon, 6 Jan 2014 13:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-287) Websocket application working
 with multiple clients (e.g. chat style applications) fails due
 NullPointerException
In-Reply-To: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528639.1389009796000.31428.1389031772905@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat resolved JBWEB-287.
----------------------------------

    Fix Version/s: JBossWeb-7.4.0.GA
       Resolution: Done


It looks like a Tomcat bug, so a null check was missing from its websockets code.
                
> Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-287
>                 URL: https://issues.jboss.org/browse/JBWEB-287
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>            Reporter: Radim Hatlapatka
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>         Attachments: byteslounge.war
>
>
> When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
> {noformat}
> 11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
> 	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> The same application correctly works with Tomcat 7

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

From issues at jboss.org  Mon Jan  6 13:15:34 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 6 Jan 2014 13:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2704) FORM authenticated identity
 lost on failover
In-Reply-To: <JIRA.12528557.1388696632000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528557.1388696632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528557.1388696632000.31440.1389032134581@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated WFLY-2704:
-------------------------------

    Summary: FORM authenticated identity lost on failover  (was: FORM authentication credentials lost on failover)

    
> FORM authenticated identity lost on failover
> --------------------------------------------
>
>                 Key: WFLY-2704
>                 URL: https://issues.jboss.org/browse/WFLY-2704
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Final
>
>
> Unlike BASIC, DIGEST, and CERT authentication, FORM authentication requires an additional server side mechanism to store the credentials from the login form so that a user does not need to reauthenticate on failover.
> Traditionally, clustered SSO was the mechanism of choice (see https://issues.jboss.org/browse/JBAS-1900 )
> An analogous strategy is needed for 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 issues at jboss.org  Mon Jan  6 13:21:33 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 6 Jan 2014 13:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-55) StatefulFailoverTestCase
 intermittently fails
In-Reply-To: <JIRA.12470733.1342648060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470733.1342648060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470733.1342648060000.31456.1389032493732@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro closed WFLY-55.
----------------------------

         Assignee: Paul Ferraro  (was: Radoslav Husar)
    Fix Version/s:     (was: 8.0.0.Final)
       Resolution: Done


This test was rewritten and should be much more stable now.
                
> StatefulFailoverTestCase intermittently fails
> ---------------------------------------------
>
>                 Key: WFLY-55
>                 URL: https://issues.jboss.org/browse/WFLY-55
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jason Greene
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase(UDP).testRestart
> Failing for the past 1 build (Since #4183 )
> Took 2 min 18 sec.
> Error Message
> expected:<200> but was:<500>
> Stacktrace
> java.lang.AssertionError: expected:<200> but was:<500>
> 	at org.junit.Assert.fail(Assert.java:93)
> 	at org.junit.Assert.failNotEquals(Assert.java:647)
> 	at org.junit.Assert.assertEquals(Assert.java:128)
> 	at org.junit.Assert.assertEquals(Assert.java:472)
> 	at org.junit.Assert.assertEquals(Assert.java:456)
> 	at org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase.queryCount(StatefulFailoverTestCase.java:256)
> 	at org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase.assertQueryCount(StatefulFailoverTestCase.java:278)
> 	at org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase.testRestart(StatefulFailoverTestCase.java:139)
> 	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: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.GeneratedMethodAccessor12.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.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.GeneratedMethodAccessor11.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java: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.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Standard Output
> 13:55:02,557 INFO  [org.jboss.web] (MSC service thread 1-2) JBAS018224: Unregister web context: /stateful
> 13:55:02,619 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 4) ISPN000029: Passivating all entries to disk
> 13:55:02,623 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 4) ISPN000030: Passivated 0 entries in 3 milliseconds
> 13:55:02,619 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 26) ISPN000029: Passivating all entries to disk
> 13:55:02,630 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> 13:55:02,630 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 26) ISPN000030: Passivated 0 entries in 8 milliseconds
> 13:55:02,633 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 2 milliseconds
> 13:55:02,644 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped default-host/stateful cache from web container
> 13:55:02,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 4) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:55:02,654 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:55:02,668 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment stateful.war
> 13:55:02,725 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000029: Passivating all entries to disk
> 13:55:02,726 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000030: Passivated 0 entries in 0 milliseconds
> 13:55:02,726 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> 13:55:02,728 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 0 entries in 1 milliseconds
> 13:55:02,737 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped repl cache from ejb container
> 13:55:02,739 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010282: Stopped repl cache from web container
> 13:55:02,753 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 13:55:02,775 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-17,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/web, node-1/web]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/web]}). This is normal during a merge
> 13:55:02,825 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment stateful.war in 298ms
> 13:55:02,786 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-17,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=default-host/stateful, type=PREPARE_VIEW, sender=node-0/web, newViewId=4, newMembers=[node-0/web, node-1/web], oldViewId=3, oldMembers=[node-0/web]}: java.lang.IllegalStateException: default-host/stateful: Received cache view prepare request after the local node has already shut down
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
> 	at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
> 	at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> 	at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
> 	at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
> 	at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> 	at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> 	at org.jgroups.JChannel.up(JChannel.java:715)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> 	at org.jgroups.protocols.RSVP.up(RSVP.java:179)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> 	at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> 	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
> 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> 	at org.jgroups.protocols.FD.up(FD.java:273)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:55:03,062 INFO  [org.jboss.as.clustering] (ViewHandler,web,node-0/web) JBAS010225: New cluster view for partition web (id: 2, delta: -1, merge: false) : [node-0/web]
> 13:55:03,063 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,web,node-0/web) ISPN000094: Received new cluster view: [node-0/web|2] [node-0/web]
> 13:55:03,098 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [node-0/ejb]
> 13:55:03,100 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|2] [node-0/ejb]
> 13:55:03,355 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher
> 13:55:03,501 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 13:55:03,559 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/5c/37165cc1c30b1263a1854cab3a82149afcf0f2/content
> 13:55:03,560 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "stateful.war"
> 13:55:03,563 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> URLs are: http://127.0.0.1:8080/stateful/count, http://127.0.0.1:8180/stateful/count
> 13:56:02,775 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-2,node-0/web) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/web, node-1/web]} for cache  default-host/stateful, rolling back to view CacheView{viewId=3, members=[node-0/web]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> 	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> 	at org.infinispan.util.Util.rewrapAsCacheException(Util.java:526) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:172) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	... 5 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> 	at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:275) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.protocols.RSVP.down(RSVP.java:114) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.JChannel.down(JChannel.java:729) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.RequestCorrelator.sendUnicastRequest(RequestCorrelator.java:202) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.UnicastRequest.sendRequest(UnicastRequest.java:44) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.Request.execute(Request.java:83) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:366) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	... 8 more
> 13:56:04,452 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (http-/127.0.0.1:8080-1) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:56:04,479 ERROR [org.infinispan.transaction.TransactionCoordinator] (http-/127.0.0.1:8080-1) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:56:04,503 ERROR [org.infinispan.transaction.tm.DummyTransaction] (http-/127.0.0.1:8080-1) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=19}, status=3}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 11} org.infinispan.transaction.synchronization.SynchronizationAdapter at 30: org.infinispan.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:83)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:223)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:176)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	... 21 more
> 13:57:04,672 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (http-/127.0.0.1:8080-1) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:57:04,697 ERROR [org.infinispan.transaction.TransactionCoordinator] (http-/127.0.0.1:8080-1) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:57:04,723 ERROR [org.infinispan.transaction.tm.DummyTransaction] (http-/127.0.0.1:8080-1) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=30}, status=3}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 1c} org.infinispan.transaction.synchronization.SynchronizationAdapter at 3b: org.infinispan.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:83)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:223)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:176)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	... 21 more
> 13:57:04,739 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 13:57:04,745 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Djboss.node.name=node-1, -Djboss.port.offset=100, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 13:57:05,648 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 13:57:05,920 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 13:57:05,990 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 13:57:07,922 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 13:57:07,927 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 13:57:07,933 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 13:57:07,945 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 13:57:08,035 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> 13:57:08,043 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> 13:57:08,079 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> 13:57:08,127 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> 13:57:08,133 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> 13:57:08,138 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:57:08,176 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> 13:57:08,246 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.9.Final
> 13:57:08,272 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-3) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.11.Final)
> 13:57:08,278 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:57:08,438 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:57:08,472 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-5) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:57:08,537 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:57:08,791 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-5) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> 13:57:09,050 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-2) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8109
> 13:57:09,062 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8180
> 13:57:09,214 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> 13:57:09,263 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> 13:57:09,336 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:09,359 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:09,535 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 13:57:09,553 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/deployments
> 13:57:09,559 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4547
> 13:57:09,560 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:10099
> 13:57:09,684 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 13:57:09,685 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 13:57:09,685 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4360ms - Started 138 of 285 services (146 services are passive or on-demand)
> 13:57:11,925 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/33/a062483bafd997e0d3374cfa764aeb07874c01/content
> 13:57:11,983 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "stateful.war"
> 13:57:12,783 INFO  [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011006: OSGi Framework - 2.0.0.CR12
> 13:57:13,163 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment stateful.war
> 13:57:13,182 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named StatefulBean in deployment unit deployment "stateful.war" are as follows:
> 	java:global/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Stateful
> 	java:app/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Stateful
> 	java:module/StatefulBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Stateful
> 	java:global/stateful/StatefulBean
> 	java:app/stateful/StatefulBean
> 	java:module/StatefulBean
> 13:57:13,183 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named NestedBean in deployment unit deployment "stateful.war" are as follows:
> 	java:global/stateful/NestedBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Nested
> 	java:app/stateful/NestedBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Nested
> 	java:module/NestedBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Nested
> 	java:global/stateful/NestedBean
> 	java:app/stateful/NestedBean
> 	java:module/NestedBean
> 13:57:13,619 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016005: Starting Services for CDI deployment: stateful.war
> 13:57:13,769 INFO  [org.jboss.weld.Version] (MSC service thread 1-5) WELD-000900 1.1.8 (Final)
> 13:57:13,975 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016008: Starting weld service for deployment stateful.war
> 13:57:14,130 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:14,131 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:14,134 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:14,536 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.ClusterHttpClientUtil because of underlying class loading error
> 13:57:14,538 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.ClusterHttpClientUtil
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:108) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:123) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	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_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NoClassDefFoundError: org/apache/http/client/methods/HttpUriRequest
> 	at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_29]
> 	at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_29]
> 	at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_29]
> 	at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:105) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:102) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:154) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
> 	at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	... 12 more
> Caused by: java.lang.ClassNotFoundException: org.apache.http.client.methods.HttpUriRequest from [Module "deployment.stateful.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> 	... 30 more
> 13:57:14,560 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.NodeUtil because of underlying class loading error
> 13:57:14,564 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.NodeUtil
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:108) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:123) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	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_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/arquillian/container/test/api/ContainerController
> 	at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.6.0_29]
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [rt.jar:1.6.0_29]
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791) [rt.jar:1.6.0_29]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:175) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:234) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
> 	at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	... 12 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.container.test.api.ContainerController from [Module "deployment.stateful.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> 	... 30 more
> 13:57:14,596 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.DMRUtil because of underlying class loading error
> 13:57:14,597 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.DMRUtil
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:108) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:123) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	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_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/dmr/ModelNode
> 	at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.6.0_29]
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [rt.jar:1.6.0_29]
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791) [rt.jar:1.6.0_29]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:175) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:234) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
> 	at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	... 12 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.dmr.ModelNode from [Module "deployment.stateful.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> 	... 30 more
> 13:57:14,661 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) send buffer of socket java.net.DatagramSocket at 475b73eb was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 13:57:14,663 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) receive buffer of socket java.net.DatagramSocket at 475b73eb was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 13:57:14,663 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) send buffer of socket java.net.MulticastSocket at 3865db85 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 13:57:14,664 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) receive buffer of socket java.net.MulticastSocket at 3865db85 was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 13:57:14,669 INFO  [stdout] (ServerService Thread Pool -- 28) 
> 13:57:14,669 INFO  [stdout] (ServerService Thread Pool -- 28) -------------------------------------------------------------------
> 13:57:14,670 INFO  [stdout] (ServerService Thread Pool -- 28) GMS: address=node-1/ejb, cluster=ejb, physical address=127.0.0.1:55300
> 13:57:14,670 INFO  [stdout] (ServerService Thread Pool -- 28) -------------------------------------------------------------------
> 13:57:14,780 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 3, delta: 1, merge: false) : [node-0/ejb, node-1/ejb]
> 13:57:14,781 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|3] [node-0/ejb, node-1/ejb]
> 13:57:14,792 INFO  [stdout] (ServerService Thread Pool -- 27) 
> 13:57:14,793 INFO  [stdout] (ServerService Thread Pool -- 27) -------------------------------------------------------------------
> 13:57:14,793 INFO  [stdout] (ServerService Thread Pool -- 27) GMS: address=node-1/web, cluster=web, physical address=127.0.0.1:55300
> 13:57:14,794 INFO  [stdout] (ServerService Thread Pool -- 27) -------------------------------------------------------------------
> 13:57:14,874 INFO  [org.jboss.as.clustering] (ViewHandler,web,node-0/web) JBAS010225: New cluster view for partition web (id: 3, delta: 1, merge: false) : [node-0/web, node-1/web]
> 13:57:14,875 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,web,node-0/web) ISPN000094: Received new cluster view: [node-0/web|3] [node-0/web, node-1/web]
> 13:57:14,991 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 27) ISPN000078: Starting JGroups Channel
> 13:57:14,992 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000078: Starting JGroups Channel
> 13:57:15,004 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 27) ISPN000094: Received new cluster view: [node-0/web|3] [node-0/web, node-1/web]
> 13:57:15,004 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000094: Received new cluster view: [node-0/ejb|3] [node-0/ejb, node-1/ejb]
> 13:57:15,006 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 27) ISPN000079: Cache local address is node-1/web, physical addresses are [127.0.0.1:55300]
> 13:57:15,006 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000079: Cache local address is node-1/ejb, physical addresses are [127.0.0.1:55300]
> 13:57:15,015 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 27) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> 13:57:15,016 INFO  [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 27) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:15,316 INFO  [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 25) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:15,408 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 26) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,426 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 28) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,445 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 25) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,448 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 27) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 25) JBAS010281: Started default-host/stateful cache from web container
> 13:57:15,655 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 27) JBAS010281: Started repl cache from web container
> 13:57:15,664 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010281: Started repl cache from ejb container
> 13:57:15,696 INFO  [org.jboss.as.clustering] (MSC service thread 1-2) JBAS010238: Number of cluster members: 2
> 13:57:15,695 INFO  [org.jboss.as.clustering] (MSC service thread 1-5) JBAS010238: Number of cluster members: 2
> 13:57:15,787 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> 13:57:15,938 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-6) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,970 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:57:15,979 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-3) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:16,025 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:57:16,074 INFO  [org.jboss.web] (MSC service thread 1-3) JBAS018210: Register web context: /stateful
> 13:57:16,120 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,137 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,138 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,139 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,491 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "stateful.war"
> 13:57:17,858 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-/127.0.0.1:8180-1) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> 	at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final.jar:]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:57:17,939 INFO  [org.jboss.web] (MSC service thread 1-3) JBAS018224: Unregister web context: /stateful
> 13:57:18,021 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 59) ISPN000029: Passivating all entries to disk
> 13:57:18,021 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000029: Passivating all entries to disk
> 13:57:18,022 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000029: Passivating all entries to disk
> 13:57:18,027 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000030: Passivated 0 entries in 5 milliseconds
> 13:57:18,032 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 59) ISPN000030: Passivated 1 entries in 11 milliseconds
> 13:57:18,041 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000030: Passivated 1 entries in 19 milliseconds
> 13:57:18,047 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 59) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:57:18,049 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010282: Stopped default-host/stateful cache from web container
> 13:57:18,064 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 58) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:57:18,076 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016009: Stopping weld service for deployment stateful.war
> 13:57:18,136 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> 13:57:18,140 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 0 entries in 4 milliseconds
> 13:57:18,150 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> 13:57:18,168 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped repl cache from web container
> 13:57:18,203 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 13:57:18,221 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 1 entries in 70 milliseconds
> 13:57:18,231 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment stateful.war in 318ms
> 13:57:18,234 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from ejb container
> 13:57:18,706 INFO  [org.jboss.as.clustering] (Incoming-2,null) JBAS010225: New cluster view for partition ejb (id: 4, delta: -1, merge: false) : [node-1/ejb]
> 13:57:18,709 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [node-1/ejb|4] [node-1/ejb]
> 13:57:18,828 INFO  [org.jboss.as.clustering] (Incoming-3,null) JBAS010225: New cluster view for partition web (id: 4, delta: -1, merge: false) : [node-1/web]
> 13:57:18,830 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,null) ISPN000094: Received new cluster view: [node-1/web|4] [node-1/web]
> 13:57:19,482 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 13:57:19,498 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher
> 13:57:19,533 INFO  [org.jboss.as.repository] (management-handler-thread - 5) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/d3/a10a6a1365e0e65c637fe0eb4722ef2f866d59/content
> 13:57:19,534 INFO  [org.jboss.as.server] (management-handler-thread - 5) JBAS018558: Undeployed "stateful.war"
> 13:57:19,536 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 13:57:19,773 INFO  [org.jboss.web] (MSC service thread 1-4) JBAS018224: Unregister web context: /stateful
> 13:57:19,810 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 28) ISPN000029: Passivating all entries to disk
> 13:57:19,813 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> 13:57:19,810 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 25) ISPN000029: Passivating all entries to disk
> 13:57:19,832 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 25) ISPN000030: Passivated 1 entries in 21 milliseconds
> 13:57:19,832 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 28) ISPN000030: Passivated 1 entries in 21 milliseconds
> 13:57:19,839 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 25) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:57:19,839 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:57:19,848 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 1 entries in 35 milliseconds
> 13:57:19,855 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016009: Stopping weld service for deployment stateful.war
> 13:57:19,874 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped default-host/stateful cache from web container
> 13:57:19,900 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> 13:57:19,900 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 0 milliseconds
> 13:57:19,906 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from web container
> 13:57:19,922 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000029: Passivating all entries to disk
> 13:57:19,920 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 13:57:19,935 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment stateful.war in 174ms
> 13:57:19,936 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000030: Passivated 1 entries in 14 milliseconds
> 13:57:19,941 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped repl cache from ejb container
> 13:57:20,232 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 13:57:20,325 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> 13:57:20,377 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/33/a062483bafd997e0d3374cfa764aeb07874c01/content
> 13:57:20,378 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "stateful.war"
> 13:57:20,380 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance

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


From issues at jboss.org  Mon Jan  6 14:05:32 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 6 Jan 2014 14:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2714) EL Comparison don't works in
	attributes
In-Reply-To: <JIRA.12528682.1389035131582@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528682.1389035131582@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528682.1389035131582.31496.1389035132747@jira02.app.mwc.hst.phx2.redhat.com>

Ot?vio Garcia created WFLY-2714:
-----------------------------------

             Summary: EL Comparison don't works in attributes
                 Key: WFLY-2714
                 URL: https://issues.jboss.org/browse/WFLY-2714
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
Wildfly 8.0.0 CR1
            Reporter: Ot?vio Garcia
            Assignee: Stuart Douglas


I have a class with BigDecimal attribute:

public class Foo {
    private BigDecimal value;
}

This code works fine

<p>${foo.value lt 0}</p>

And this code too:

<p>${foo.value lt 0 ? 'negative' : 'positive'}</p>

But when I use the expression in the attribute, I get the errot bellow:

<p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>

The class 'Foo' does not have the property 'valuelt0'.

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


From issues at jboss.org  Mon Jan  6 14:07:32 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 6 Jan 2014 14:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2714) EL Comparison don't works in
	attributes
In-Reply-To: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528682.1389035131000.31499.1389035252957@jira02.app.mwc.hst.phx2.redhat.com>


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

Ot?vio Garcia updated WFLY-2714:
--------------------------------

    Labels: el wildfly  (was: )

    
> EL Comparison don't works in attributes
> ---------------------------------------
>
>                 Key: WFLY-2714
>                 URL: https://issues.jboss.org/browse/WFLY-2714
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> Wildfly 8.0.0 CR1
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>              Labels: el, wildfly
>
> I have a class with BigDecimal attribute:
> public class Foo {
>     private BigDecimal value;
> }
> This code works fine
> <p>${foo.value lt 0}</p>
> And this code too:
> <p>${foo.value lt 0 ? 'negative' : 'positive'}</p>
> But when I use the expression in the attribute, I get the errot bellow:
> <p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>
> The class 'Foo' does not have the property 'valuelt0'.

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


From issues at jboss.org  Mon Jan  6 14:09:32 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 6 Jan 2014 14:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2714) EL Comparison don't works in
	attributes
In-Reply-To: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528682.1389035131000.31503.1389035372949@jira02.app.mwc.hst.phx2.redhat.com>


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

Ot?vio Garcia updated WFLY-2714:
--------------------------------

    Description: 
I have a class with BigDecimal attribute:

{code:java}
public class Foo {
    private BigDecimal value;
}
{code}

This code works fine

<p>${foo.value lt 0}</p>

And this code too:

<p>${foo.value lt 0 ? 'negative' : 'positive'}</p>

But when I use the expression in the attribute, I get the errot bellow:

<p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>

The class 'Foo' does not have the property 'valuelt0'.

  was:
I have a class with BigDecimal attribute:

public class Foo {
    private BigDecimal value;
}

This code works fine

<p>${foo.value lt 0}</p>

And this code too:

<p>${foo.value lt 0 ? 'negative' : 'positive'}</p>

But when I use the expression in the attribute, I get the errot bellow:

<p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>

The class 'Foo' does not have the property 'valuelt0'.


    
> EL Comparison don't works in attributes
> ---------------------------------------
>
>                 Key: WFLY-2714
>                 URL: https://issues.jboss.org/browse/WFLY-2714
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> Wildfly 8.0.0 CR1
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>              Labels: el, wildfly
>
> I have a class with BigDecimal attribute:
> {code:java}
> public class Foo {
>     private BigDecimal value;
> }
> {code}
> This code works fine
> <p>${foo.value lt 0}</p>
> And this code too:
> <p>${foo.value lt 0 ? 'negative' : 'positive'}</p>
> But when I use the expression in the attribute, I get the errot bellow:
> <p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>
> The class 'Foo' does not have the property 'valuelt0'.

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


From issues at jboss.org  Mon Jan  6 14:09:33 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 6 Jan 2014 14:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2714) EL Comparison don't works in
	attributes
In-Reply-To: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528682.1389035131000.31505.1389035373118@jira02.app.mwc.hst.phx2.redhat.com>


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

Ot?vio Garcia updated WFLY-2714:
--------------------------------

    Description: 
I have a class with BigDecimal attribute:

{code:java}
public class Foo {
    private BigDecimal value;
}
{code}

This code works fine

{code:xml}
<p>${foo.value lt 0}</p>
{code}

And this code too:

{code:xml}
<p>${foo.value lt 0 ? 'negative' : 'positive'}</p>
{code}

But when I use the expression in the attribute, I get the errot bellow:

{code:xml}
<p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>
{code}

The class 'Foo' does not have the property 'valuelt0'.

  was:
I have a class with BigDecimal attribute:

{code:java}
public class Foo {
    private BigDecimal value;
}
{code}

This code works fine

<p>${foo.value lt 0}</p>

And this code too:

<p>${foo.value lt 0 ? 'negative' : 'positive'}</p>

But when I use the expression in the attribute, I get the errot bellow:

<p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>

The class 'Foo' does not have the property 'valuelt0'.


    
> EL Comparison don't works in attributes
> ---------------------------------------
>
>                 Key: WFLY-2714
>                 URL: https://issues.jboss.org/browse/WFLY-2714
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> Wildfly 8.0.0 CR1
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>              Labels: el, wildfly
>
> I have a class with BigDecimal attribute:
> {code:java}
> public class Foo {
>     private BigDecimal value;
> }
> {code}
> This code works fine
> {code:xml}
> <p>${foo.value lt 0}</p>
> {code}
> And this code too:
> {code:xml}
> <p>${foo.value lt 0 ? 'negative' : 'positive'}</p>
> {code}
> But when I use the expression in the attribute, I get the errot bellow:
> {code:xml}
> <p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>
> {code}
> The class 'Foo' does not have the property 'valuelt0'.

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


From issues at jboss.org  Mon Jan  6 15:45:33 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 6 Jan 2014 15:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-779) Release PicketBox
	4.0.20.Beta3
In-Reply-To: <JIRA.12528685.1389041053790@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528685.1389041053790@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528685.1389041053790.31586.1389041133144@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created SECURITY-779:
---------------------------------------

             Summary: Release PicketBox 4.0.20.Beta3
                 Key: SECURITY-779
                 URL: https://issues.jboss.org/browse/SECURITY-779
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen




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

From issues at jboss.org  Mon Jan  6 16:39:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 6 Jan 2014 16:39:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-779) Release PicketBox
	4.0.20.Beta3
In-Reply-To: <JIRA.12528685.1389041053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528685.1389041053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528685.1389041053000.31699.1389044372673@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefan Guilhen closed SECURITY-779.
-----------------------------------

    Resolution: Done


PicketBox 4.0.20.Beta3 has been released and is available on Nexus.
                
> Release PicketBox 4.0.20.Beta3
> ------------------------------
>
>                 Key: SECURITY-779
>                 URL: https://issues.jboss.org/browse/SECURITY-779
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>


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

From issues at jboss.org  Mon Jan  6 17:15:34 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 6 Jan 2014 17:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-100) JBossLogManagerLogger
 unconditionally does string conversion
In-Reply-To: <JIRA.12528621.1388850245000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528621.1388850245000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528621.1388850245000.31781.1389046534029@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins commented on JBLOGGING-100:
-----------------------------------------

Just to put it here too. IMO the message should always be a string. Even trace or debug log messages should have something more informative than {{Object.toString()}}. For example if you object is {{null}} that's not much of a message to be printing. It doesn't really tell you anything. 

Also while {{java.lang.Object}} is the argument type only log4j supports it. JBoss Log Manager, log4j2 and slf4j only support string message types.
                
> JBossLogManagerLogger unconditionally does string conversion
> ------------------------------------------------------------
>
>                 Key: JBLOGGING-100
>                 URL: https://issues.jboss.org/browse/JBLOGGING-100
>             Project: JBoss Logging
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-logmanager
>    Affects Versions: 3.1.3.GA
>            Reporter: Philippe Marschall
>            Assignee: James Perkins
>
> {{JBossLogManagerLogger#doLog}} always converts the message to a String even if the level isn't loggable. This can have a negative performance impact and result in a lot of unnecessary allocations.
> For example {{LogAuditProvider#audit}} does trace logging which ends up calling {{AuditEvent#toString}} even if trace logging isn't enabled. In our case this results in a lot of allocations outside of TLABs.

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

From issues at jboss.org  Mon Jan  6 17:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 6 Jan 2014 17:21:33 -0500 (EST)
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.31797.1389046893471@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 984855|https://bugzilla.redhat.com/show_bug.cgi?id=984855] from NEW to POST
                
> 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
>      Security Level: Public(Everyone can see) 
>          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.Final
>
>
> 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 issues at jboss.org  Mon Jan  6 17:33:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 6 Jan 2014 17:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2651) JBAS014160: Wrong tx on
 thread when calling async EJB method from async servlet
In-Reply-To: <JIRA.12527921.1386942083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527921.1386942083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527921.1386942083000.31801.1389047613087@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2651:
------------------------------------

    Assignee: Stuart Douglas  (was: Scott Marlow)

    
>  JBAS014160: Wrong tx on thread when calling async EJB method from async servlet 
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2651
>                 URL: https://issues.jboss.org/browse/WFLY-2651
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Fedora 19, OpenJDK 1.7.0
>            Reporter: Eldar Yusupov
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>         Attachments: async-testcase-1.0-SNAPSHOT.war
>
>
> When trying to execute asynchronous EJB bean from asynchronous servlet, the following exception is thrown (testcase is available at https://github.com/eyusupov/async-testcase/):
> 2013-12-13 00:42:03,489 ERROR [org.jboss.as.txn] (EJB default - 1) JBAS010152: APPLICATION ERROR: transaction still active in request with status 0
> 2013-12-13 00:42:03,494 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) JBAS014134: EJB Invocation failed on component AsyncBean for method public void com.okasamastarr.web.AsyncBean.count(javax.servlet.AsyncContext) throws java.io.IOException: java.lang.IllegalStateException: JBAS014160: Wrong tx on thread: expected TransactionImple < ac, BasicAction: 0:ffffac1e0f02:-40b55bbb:52aa1f96:8 status: ActionStatus.ABORTED >, actual null
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:85) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java: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.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$1.runInvocation(AsyncFutureInterceptorFactory.java:87) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     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 message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan  6 17:33:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 6 Jan 2014 17:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2651) JBAS014160: Wrong tx on
 thread when calling async EJB method from async servlet
In-Reply-To: <JIRA.12527921.1386942083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527921.1386942083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527921.1386942083000.31803.1389047613183@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2651:
--------------------------------------

This does appear to be an Undertow issue. I will have a look into it. 
                
>  JBAS014160: Wrong tx on thread when calling async EJB method from async servlet 
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2651
>                 URL: https://issues.jboss.org/browse/WFLY-2651
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Fedora 19, OpenJDK 1.7.0
>            Reporter: Eldar Yusupov
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>         Attachments: async-testcase-1.0-SNAPSHOT.war
>
>
> When trying to execute asynchronous EJB bean from asynchronous servlet, the following exception is thrown (testcase is available at https://github.com/eyusupov/async-testcase/):
> 2013-12-13 00:42:03,489 ERROR [org.jboss.as.txn] (EJB default - 1) JBAS010152: APPLICATION ERROR: transaction still active in request with status 0
> 2013-12-13 00:42:03,494 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 1) JBAS014134: EJB Invocation failed on component AsyncBean for method public void com.okasamastarr.web.AsyncBean.count(javax.servlet.AsyncContext) throws java.io.IOException: java.lang.IllegalStateException: JBAS014160: Wrong tx on thread: expected TransactionImple < ac, BasicAction: 0:ffffac1e0f02:-40b55bbb:52aa1f96:8 status: ActionStatus.ABORTED >, actual null
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:85) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     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.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
>     at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>     at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java: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.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>     at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$1.runInvocation(AsyncFutureInterceptorFactory.java:87) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
>     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 message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan  6 18:29:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 6 Jan 2014 18:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.31843.1389050972870@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2595:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038305, https://bugzilla.redhat.com/show_bug.cgi?id=1049074  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1038305)

    
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

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

From issues at jboss.org  Mon Jan  6 19:11:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 6 Jan 2014 19:11:33 -0500 (EST)
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.31858.1389053493001@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2061:
-----------------------------------

    Fix Version/s: 8.0.0.Final
         Assignee: Brian Stansberry  (was: Jason Greene)
      Component/s: Domain Management
                       (was: CLI)
                       (was: Server)

    
> 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
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Mon Jan  6 19:17:32 2014
From: issues at jboss.org (Jonathan Laterreur (JIRA))
Date: Mon, 6 Jan 2014 19:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-143)
 javax.persistence.validation.mode in persistence.xml don't work
In-Reply-To: <JIRA.12528695.1389053783908@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528695.1389053783908@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528695.1389053783908.31864.1389053852778@jira02.app.mwc.hst.phx2.redhat.com>

Jonathan Laterreur created HIBERNATE-143:
--------------------------------------------

             Summary: javax.persistence.validation.mode in persistence.xml don't work
                 Key: HIBERNATE-143
                 URL: https://issues.jboss.org/browse/HIBERNATE-143
             Project: Hibernate Integration
          Issue Type: Bug
         Environment: Weblogic 12.1.2 / Windows / Hibernate 4.3.0.Final
            Reporter: Jonathan Laterreur
            Assignee: Steve Ebersole
            Priority: Minor


Hi, 
I tried to set javax.persistence.validation.mode to none in the persistence.xml but it don't work. ValidationMode.java in the Hibernate-Core always return AUTO. 

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

From issues at jboss.org  Mon Jan  6 19:43:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 6 Jan 2014 19:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2715) Upgrade to PicketBox
	4.0.20.Beta3
In-Reply-To: <JIRA.12528696.1389055292802@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528696.1389055292802@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528696.1389055292802.31874.1389055412702@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created WFLY-2715:
------------------------------------

             Summary: Upgrade to PicketBox 4.0.20.Beta3
                 Key: WFLY-2715
                 URL: https://issues.jboss.org/browse/WFLY-2715
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.CR1
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: 8.0.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 issues at jboss.org  Mon Jan  6 19:53:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 6 Jan 2014 19:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2715) Upgrade to PicketBox
	4.0.20.Beta3
In-Reply-To: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528696.1389055292000.31876.1389056012835@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefan Guilhen updated WFLY-2715:
---------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5674

    
> Upgrade to PicketBox 4.0.20.Beta3
> ---------------------------------
>
>                 Key: WFLY-2715
>                 URL: https://issues.jboss.org/browse/WFLY-2715
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.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 issues at jboss.org  Mon Jan  6 21:03:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 6 Jan 2014 21:03:32 -0500 (EST)
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.31896.1389060212938@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2061:
----------------------------------------

@karjoe,

The WFLY-1521 fix should have fixed the EJB subsystem issue you mentioned. You're correct; it was due to the same basic problem: looking up an MSC service using the deployment name to create the service name instead of using the 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
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Mon Jan  6 23:43:32 2014
From: issues at jboss.org (Sean Flanigan (JIRA))
Date: Mon, 6 Jan 2014 23:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM
 authentication does not work with httpd+JBossEAP6 if SPNEGO not available
In-Reply-To: <JIRA.12482678.1358326298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482678.1358326298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482678.1358326298000.31962.1389069812890@jira02.app.mwc.hst.phx2.redhat.com>


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

Sean Flanigan commented on SECURITY-722:
----------------------------------------

This happened to us too.  The problem is three-fold: 
1. If httpd.conf has ProxyErrorOverride On, the 401 login form will be replaced with a custom error page.
2. org.jboss.security.negotiation.NegotiationAuthenticator apparently doesn't set a contentType for the 401 Response.
3. Apache httpd sees that the response has no Content-Type, and adds a Content-Type header using the DefaultType, which defaults to "text/plain".

See http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype

So the workaround is to edit /etc/httpd/conf/httpd.conf, remove "ProxyErrorOverride On"  and set "DefaultType none" instead of "DefaultType text/plain".

Another option (instead of changing DefaultType) would be to override the method {{org.jboss.security.negotiation.NegotiationAuthenticator.authenticate()}} so that contentType is set to "text/html", and to activate it as a valve in jboss-web.xml:

{{<valve><class-name>com.example.CustomNegotiationAuthenticator</class-name></valve>}}

But it would be better to change org.jboss.security.negotiation.NegotiationAuthenticator.authenticate() so that it sets contentType on the Response itself.

                
> SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available
> -------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-722
>                 URL: https://issues.jboss.org/browse/SECURITY-722
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_1
>         Environment: RHEL6, JBoss EAP 6
>            Reporter: flame liu
>            Assignee: Darran Lofthouse
>
> I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated.
> After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out.

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

From issues at jboss.org  Tue Jan  7 00:09:32 2014
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Tue, 7 Jan 2014 00:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-90) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367953@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367953@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367953.31974.1389071372799@jira02.app.mwc.hst.phx2.redhat.com>

Osamu Nagano created LOGMGR-90:
----------------------------------

             Summary: Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
                 Key: LOGMGR-90
                 URL: https://issues.jboss.org/browse/LOGMGR-90
             Project: JBoss Log Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.Final
         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
            Reporter: Osamu Nagano
            Assignee: David Lloyd


Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 00:21:32 2014
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Tue, 7 Jan 2014 00:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-90) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.31977.1389072092743@jira02.app.mwc.hst.phx2.redhat.com>


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

Osamu Nagano commented on LOGMGR-90:
------------------------------------

Here is a GC root path from a web app's class loader.  I can attach the heapdump if you like.

{code}
Class Name                                                                                                     | Shallow Heap | Retained Heap
----------------------------------------------------------------------------------------------------------------------------------------------
org.jboss.modules.ModuleClassLoader @ 0xf94269b8                                                               |           88 |       104,480
'- key org.jboss.logmanager.FastCopyHashMap$Entry @ 0xf9448fa0                                                 |           24 |            24
   '- [67] org.jboss.logmanager.FastCopyHashMap$Entry[128] @ 0xf94e12a0                                        |          528 |           912
      '- table org.jboss.logmanager.FastCopyHashMap @ 0xf94e1268                                               |           56 |           968
         '- map org.jboss.logmanager.CopyOnWriteMap @ 0xf8a1fba8                                               |           24 |           992
            '- contextMap org.jboss.logmanager.ClassLoaderLogContextSelector @ 0xf8a1fb80                      |           24 |         1,600
               '- delegate org.jboss.logmanager.ThreadLocalLogContextSelector @ 0xf8a1fb68                     |           24 |            24
                  '- logContextSelector class org.jboss.logmanager.LogContext @ 0xf8a1fad8                     |           32 |           296
                     |- <class> org.jboss.logmanager.LogContext @ 0xf89978c8                                   |           40 |           104
                     |  |- context org.jboss.logmanager.LoggerNode @ 0xf8027970                                |           56 |           136
                     |  |  '- loggerNode org.jboss.logmanager.Logger @ 0xf802b5f8                              |           72 |           160
                     |  |     '- MLET_LOGGER class com.sun.jmx.defaults.JmxProperties @ 0xf80282d0 System Class|          112 |         3,272
                     |  |- ...
                     |  '- Total: 15 entries                                                                   |              |              
                     |- [6] java.lang.Object[160] @ 0xf8a0e408                                                 |          656 |         3,536
                     |  '- elementData java.util.Vector @ 0xf8a0e3e8                                           |           32 |         3,568
                     |     '- classes org.jboss.modules.ModuleClassLoader @ 0xf8a0ddc8                         |           88 |        30,456
                     |        '- <classloader> class org.jboss.logmanager.LogManager @ 0xf8a49ca0              |            0 |             0
                     |           '- <class> org.jboss.logmanager.LogManager @ 0xf899e7b0                       |           48 |         1,288
                     |              |- manager class java.util.logging.LogManager @ 0xf899e880 System Class    |           24 |            24
                     |              |- manager java.util.logging.Logger @ 0xf899f4f0                           |           72 |           160
                     |              |  '- global class java.util.logging.Logger @ 0xf899f468 System Class      |           24 |            56
----------------------------------------------------------------------------------------------------------------------------------------------
{code}
                
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: LOGMGR-90
>                 URL: https://issues.jboss.org/browse/LOGMGR-90
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.Final
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 00:23:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 00:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.31980.1389072212788@jira02.app.mwc.hst.phx2.redhat.com>


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

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

James Perkins <jperkins at redhat.com> changed the Status of [bug 1038305|https://bugzilla.redhat.com/show_bug.cgi?id=1038305] from NEW to POST
                
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

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

From issues at jboss.org  Tue Jan  7 00:27:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 00:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-90) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.31997.1389072452857@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated LOGMGR-90:
------------------------------------------

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

    
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: LOGMGR-90
>                 URL: https://issues.jboss.org/browse/LOGMGR-90
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.Final
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 00:31:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 00:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.32000.1389072692780@jira02.app.mwc.hst.phx2.redhat.com>


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

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

James Perkins <jperkins at redhat.com> changed the Status of [bug 1049074|https://bugzilla.redhat.com/show_bug.cgi?id=1049074] from ASSIGNED to POST
                
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

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

From issues at jboss.org  Tue Jan  7 00:35:32 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 7 Jan 2014 00:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2716) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.32004.1389072932766@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins moved LOGMGR-90 to WFLY-2716:
-------------------------------------------

              Project: WildFly  (was: JBoss Log Manager)
                  Key: WFLY-2716  (was: LOGMGR-90)
    Affects Version/s:     (was: 1.4.0.Final)

    
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2716
>                 URL: https://issues.jboss.org/browse/WFLY-2716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: David Lloyd
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 00:35:32 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 7 Jan 2014 00:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2716) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.32008.1389072932958@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins reassigned WFLY-2716:
-----------------------------------

    Assignee: James Perkins  (was: David Lloyd)

    
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2716
>                 URL: https://issues.jboss.org/browse/WFLY-2716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: James Perkins
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 00:37:32 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 7 Jan 2014 00:37:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2716) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.32012.1389073052933@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins resolved WFLY-2716.
---------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Duplicate Issue


Marking as duplicate of WFLY-2595
                
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2716
>                 URL: https://issues.jboss.org/browse/WFLY-2716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 00:37:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 7 Jan 2014 00:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2716) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.32014.1389073053029@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins updated WFLY-2716:
--------------------------------

    Component/s: Logging

    
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2716
>                 URL: https://issues.jboss.org/browse/WFLY-2716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 02:47:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jan 2014 02:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from
 the internal thread pool should not do work stealing
In-Reply-To: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524440.1383823189000.32040.1389080852714@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1732 at 1/7/14 2:46 AM:
--------------------------------------------------------

OK, the reason is that UNICAST3 corrects the above scenario quickly (within xmit_interval ms), whereas NAKACK2 has to wait until the next stability message (STABLE), which is seconds by default.
Reverting the change for NAKACK2.
                
      was (Author: belaban):
    OK, the reason is that UNICAST3 corrects the above scenario quickly (within xmit_interval ms), whereas NAKACK2 has to wait until the next stability message (STABLE), which is seconds by default.
Reverting the changr for NAKACK2.
                  
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1732
>                 URL: https://issues.jboss.org/browse/JGRP-1732
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns

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

From issues at jboss.org  Tue Jan  7 02:53:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jan 2014 02:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from
 the internal thread pool should not do work stealing
In-Reply-To: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524440.1383823189000.32042.1389081212757@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban reopened JGRP-1732:
----------------------------



There's a problem with not doing work stealing:

* We have A sending unicast messages to B
* A sends 5, 6(OOB|INTERNAL), 7
* B receives regular message 5 and delivers it
* B receives regular message 7 and queues it
* B receives OOB|INTERNAL message 6 and delivers it
** Since message 6 is marked as OOB|INTERNAL, the thread returns and does not perform any work stealing, ie. it does not deliver message 7
* B sends an ACK for 8 to A
** The problem is that now A does *not retransmit A:8*, so it could be picked up by a new thread and get delivered !
==> Message A:8 will not get delivered until A sends another message !
                
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1732
>                 URL: https://issues.jboss.org/browse/JGRP-1732
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns

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

From issues at jboss.org  Tue Jan  7 02:55:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jan 2014 02:55:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from
 the internal thread pool should not do work stealing
In-Reply-To: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524440.1383823189000.32045.1389081332660@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1732:
--------------------------------

This can be reproduced with UPerf and 1 sender thread, sending messages to itself: every now and then the sender thread times out on the RPC because the request is not delivered and so no response is received.
When using multiple sender threads, the problem is less likely to occur as different threads will pick up 'leftover' messages and deliver them.
                
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1732
>                 URL: https://issues.jboss.org/browse/JGRP-1732
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns

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

From issues at jboss.org  Tue Jan  7 02:59:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jan 2014 02:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from
 the internal thread pool should not do work stealing
In-Reply-To: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524440.1383823189000.32049.1389081572944@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1732:
--------------------------------

Possible solutions:
# Ack a message only when it has been *delivered* not *received*. The problem here is that delivery might take a while and so the sender would keep resending the message, which leads to unnecessary traffic.
# After delivery of an INTERNAL|OOB message, check if there are more messages in the table. If so, pick a thread from the regular thread pool to remove and deliver them.
                
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1732
>                 URL: https://issues.jboss.org/browse/JGRP-1732
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns

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

From issues at jboss.org  Tue Jan  7 03:25:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 03:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-23) Debugging rules impossible
In-Reply-To: <JIRA.12484002.1359724634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484002.1359724634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484002.1359724634000.32095.1389083133631@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 958381|https://bugzilla.redhat.com/show_bug.cgi?id=958381] from ON_QA to VERIFIED
                
> Debugging rules impossible
> --------------------------
>
>                 Key: DROOLS-23
>                 URL: https://issues.jboss.org/browse/DROOLS-23
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Eclipse Juno, Windows 8
>            Reporter: Marc Dzaebel
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Final
>
>
> Create Drools Project, set breakpoint, debug as Drools Application
> --> No debug

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

From issues at jboss.org  Tue Jan  7 03:25:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 03:25:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3676) drl cann't debuging in
	Eclipse IDE
In-Reply-To: <JIRA.12478455.1351822060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478455.1351822060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478455.1351822060000.32107.1389083134534@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3676:
--------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 958381|https://bugzilla.redhat.com/show_bug.cgi?id=958381] from ON_QA to VERIFIED
                
> drl cann't debuging in Eclipse IDE
> ----------------------------------
>
>                 Key: JBRULES-3676
>                 URL: https://issues.jboss.org/browse/JBRULES-3676
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.5.0.CR1
>         Environment: Eclipse 4.2?JDK1.7?Drools5.5CR1
>            Reporter: hongkun an
>            Assignee: Mark Proctor
>
> i follow url content
> http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/ch08.html
> I want debug drl example?HelloWord?in eclipse ide?but?only debug java file?cann't debug drl?why?

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


From issues at jboss.org  Tue Jan  7 03:41:32 2014
From: issues at jboss.org (Radim Hatlapatka (JIRA))
Date: Tue, 7 Jan 2014 03:41:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-287) Websocket application working
 with multiple clients (e.g. chat style applications) fails due
 NullPointerException
In-Reply-To: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528639.1389009796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528639.1389009796000.32128.1389084092930@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hatlapatka closed JBWEB-287.
----------------------------------



Verified that the fix done in revision r2334 on 7.4.x branch fixes the issue
                
> Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBWEB-287
>                 URL: https://issues.jboss.org/browse/JBWEB-287
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>            Reporter: Radim Hatlapatka
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.4.0.GA
>
>         Attachments: byteslounge.war
>
>
> When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
> {noformat}
> 11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
> 	at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> The same application correctly works with Tomcat 7

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

From issues at jboss.org  Tue Jan  7 03:43:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 03:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1716) NoClassDefFoundError:
 org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
In-Reply-To: <JIRA.12496755.1374137088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496755.1374137088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496755.1374137088000.32144.1389084213959@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-1716.
----------------------------------

    Resolution: Done


This was fixed a while ago
                
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1716
>                 URL: https://issues.jboss.org/browse/WFLY-1716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Win 7, JEE 6, JDK 7
>            Reporter: Oliver Pfau
>            Assignee: Stuart Douglas
>              Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> 	at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
>     Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         
> 		<all other services>
>     ]
> }

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

From issues at jboss.org  Tue Jan  7 03:45:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 03:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1421) Listing JNDI tree from
 container when an entry is not available causes exception
In-Reply-To: <JIRA.12493206.1369911300000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493206.1369911300000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493206.1369911300000.32147.1389084333492@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated WFLY-1421:
---------------------------------

    Fix Version/s: Awaiting Volunteers
         Assignee:     (was: Stuart Douglas)

    
> Listing JNDI tree from container when an entry is not available causes exception
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1421
>                 URL: https://issues.jboss.org/browse/WFLY-1421
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jan Martiska
>             Fix For: Awaiting Volunteers
>
>
> When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
> How to reproduce:
> Bind a federated JNDI context, like so:
> {noformat}
> /subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
> {noformat}
> then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..). 
> *Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
> After that, do this in a deployed application:
> {noformat}
> InitialContext ctx = new InitialContext();
> ctx.listBindings("java:global");
> {noformat}
> it will throw a NamingException after the connection attempt times out.
> {noformat}
> javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
> 	at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
> 	at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
> 	at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
> 	at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
> 	at ListingServlet.doGet(ListingServlet.java:30)	... 33 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> 	at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> 	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.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> 	at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
> 	at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> 	... 40 more
> Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
> 	at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
> 	at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
> 	at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
> 	... 47 more
> Caused by: java.net.ConnectException: Connection timed out
> 	at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
> 	at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
> 	at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
> 	at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
> 	at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
> 	at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
> 	... 60 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 issues at jboss.org  Tue Jan  7 03:47:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 03:47:33 -0500 (EST)
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.32162.1389084453321@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2118.
----------------------------------

    Resolution: Rejected


After talking to a few people about this I think we will just go with the current behaviour by default, as it is more developer friendly. 
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          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 issues at jboss.org  Tue Jan  7 03:51:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 03:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-356) KieScanner doesn't work on a
 KieContainer using a maven version range
In-Reply-To: <JIRA.12526413.1385632387000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526413.1385632387000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526413.1385632387000.32192.1389084693865@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1035685|https://bugzilla.redhat.com/show_bug.cgi?id=1035685] from ON_QA to VERIFIED
                
> KieScanner doesn't work on a KieContainer using a maven version range
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-356
>                 URL: https://issues.jboss.org/browse/DROOLS-356
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> It is currently possible to create a KieContainer with a ranged version instead of a fixed one, but this range is not used by the KieScanner that instead consider only the fixed version of the first fetched 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 issues at jboss.org  Tue Jan  7 03:51:34 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 03:51:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2369) request.getSession() throws
 IllegalStateException in distributable webapp
In-Reply-To: <JIRA.12508629.1382568353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508629.1382568353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508629.1382568353000.32195.1389084694253@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2369:
--------------------------------------

[~pferraro] do you have any idea what could be causing this? It looks like the initial getSession() call returns null, but then the createSession() call throws the IllegalStateException. 
                
> request.getSession() throws IllegalStateException in distributable webapp
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2369
>                 URL: https://issues.jboss.org/browse/WFLY-2369
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jonathan Fuerth
>            Assignee: Stuart Douglas
>
> A webapp I'm working is experiencing an IllegalStateException from calling the no-args request.getSession() method. The app has the <distributable/> marker in its web.xml. Taking <distributable/> out makes this issue go away.
> Here is the stack trace:
> {code}
> 17:29:05,728 DEBUG [org.uberfire.security.server.UberFireSecurityFilter] (default task-1) Authentication failure. Sending HTTP 401 response.: org.uberfire.security.auth.AuthenticationException: Validation fails.
> 	at org.uberfire.security.server.HttpSecurityManagerImpl.authenticate(HttpSecurityManagerImpl.java:220) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> 	at org.uberfire.security.server.UberFireSecurityFilter.authenticate(UberFireSecurityFilter.java:333) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> 	at org.uberfire.security.server.UberFireSecurityFilter.doFilter(UberFireSecurityFilter.java:277) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	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.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	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: UT000028: Session Q2FoOHf4ij6rcxT6v_9WsBOG already exists
> 	at org.wildfly.clustering.web.undertow.session.SessionManagerAdapter.createSession(SessionManagerAdapter.java:98)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:680) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:340) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:345) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.uberfire.security.server.auth.HttpSessionStorage.load(HttpSessionStorage.java:36) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> 	at org.uberfire.security.server.auth.HttpAuthenticationManager.authenticate(HttpAuthenticationManager.java:87) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> 	at org.uberfire.security.server.HttpSecurityManagerImpl.authenticate(HttpSecurityManagerImpl.java:216) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
> 	... 25 more
> {code}
> In case you need to see it, the source code for the app that generated this trace is at https://github.com/jfuerth/errai-cdi-workbench/tree/11794888a873ae7182524d7978215a8e36002fa1
> For completeness, the snapshot versions of its dependencies come from these git commits in the respective projects.
> * Errai: bd130e238ed39a90d513e366336b0e20b8761146
> * UberFire: 3756076ce8005ba1b0cbab6745b5d274c97d56d8
> If you need to dig this deep, please ping me. I'm happy to help :)

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

From issues at jboss.org  Tue Jan  7 04:11:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 04:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2682) Conversation identifier does
 not get incremented
In-Reply-To: <JIRA.12528381.1387815561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528381.1387815561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528381.1387815561000.32228.1389085892956@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2682.
----------------------------------

    Resolution: Cannot Reproduce Bug


Just tried this out and it seems to work fine for me. If you have a test case that reproduces it please attach it and re-open.
                
> Conversation identifier does not get incremented
> ------------------------------------------------
>
>                 Key: WFLY-2682
>                 URL: https://issues.jboss.org/browse/WFLY-2682
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows 7
>            Reporter: Adriano Scheffer
>            Assignee: Stuart Douglas
>
> The conversation id is not getting incremented when I open another browser tab. Conversely, this problems was not happening in 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 issues at jboss.org  Tue Jan  7 04:17:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-367) Kie-ci doesn't try to access
 additional remote repositories declared in settings.xml
In-Reply-To: <JIRA.12527211.1386328527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527211.1386328527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527211.1386328527000.32243.1389086253100@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1039016|https://bugzilla.redhat.com/show_bug.cgi?id=1039016] from VERIFIED to ASSIGNED
                
> Kie-ci doesn't try to access additional remote repositories declared in settings.xml
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-367
>                 URL: https://issues.jboss.org/browse/DROOLS-367
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> In maven's settings.xml file it is possible to create additional profiles and declare additional remote repositories as in:
> {code}
>   <profiles>
>     <profile>
>       <id>guvnor-m2-profile</id>
>       <activation>
>         <activeByDefault>true</activeByDefault>
>       </activation>
>       <repositories>
>         <repository>
>           <id>guvnor-m2-repo</id>
>           <name>Guvnor M2 Repo</name>
>           <url>http://localhost:8080/m-kie-drools-wb-distribution-wars-6.0.0.Final-jboss-as7.0/maven2</url>
>         </repository>
>       </repositories>
>     </profile>
>   </profiles>
> {code}
> However kie-ci doesn't try to access this further repositories (as it should) when resolving a kjar.

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

From issues at jboss.org  Tue Jan  7 04:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-378) Do not refire rules on
	unblock
In-Reply-To: <JIRA.12527977.1387077235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527977.1387077235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527977.1387077235000.32256.1389086493200@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1038076|https://bugzilla.redhat.com/show_bug.cgi?id=1038076] from MODIFIED to ON_QA
                
> Do not refire rules on unblock
> ------------------------------
>
>                 Key: DROOLS-378
>                 URL: https://issues.jboss.org/browse/DROOLS-378
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>
> If a rule is blocked (using the declarative agenda) after it has been fired, it will refire when the blocker is 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 issues at jboss.org  Tue Jan  7 04:23:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 04:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32259.1389086612866@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2703:
------------------------------------

    Assignee: Stuart Douglas

    
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 04:25:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:25:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2616) SEVERE is not an available
 logging level in the CLI
In-Reply-To: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527159.1386289598000.32267.1389086732895@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1040083|https://bugzilla.redhat.com/show_bug.cgi?id=1040083] from POST to MODIFIED
                
> SEVERE is not an available logging level in the CLI
> ---------------------------------------------------
>
>                 Key: WFLY-2616
>                 URL: https://issues.jboss.org/browse/WFLY-2616
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Kyle Lape
>            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 issues at jboss.org  Tue Jan  7 04:25:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-376) NullPointerException on
 JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is
 modified
In-Reply-To: <JIRA.12527774.1386839957000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527774.1386839957000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527774.1386839957000.32278.1389086733440@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1040889|https://bugzilla.redhat.com/show_bug.cgi?id=1040889] from MODIFIED to ON_QA
                
> NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is modified
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-376
>                 URL: https://issues.jboss.org/browse/DROOLS-376
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> - Using JPAKnowledgeService
> - Add two or more elements to Collection property which is referred by 'from' in a rule.
> {noformat}
> package org.drools.test
> import org.drools.compiler.Person
> import org.drools.compiler.Address
> rule rule1
> when
>  $p: Person($list : addresses)
>  $a: Address(street == "y") from $list
> then
>  $list.add( new Address("z") );
>  $list.add( new Address("w") );
> end
> {noformat}
> - Call JPAKnowledgeService.loadStatefulKnowledgeSession()
> Then NullPointerException is thrown
> {noformat}
> 2013-12-12 18:03:31,329 [main] |org.drools.persistence.SingleSessionCommandService| WARN  Could not commit session
> java.lang.RuntimeException: Unable to load session snapshot
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88) ~[classes/:na]
> 	at org.drools.persistence.SingleSessionCommandService.initExistingKnowledgeSession(SingleSessionCommandService.java:264) ~[classes/:na]
> 	at org.drools.persistence.SingleSessionCommandService.<init>(SingleSessionCommandService.java:196) ~[classes/:na]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.7.0_13]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [na:1.7.0_13]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.7.0_13]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [na:1.7.0_13]
> 	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.buildCommandService(KnowledgeStoreServiceImpl.java:101) [classes/:na]
> 	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadKieSession(KnowledgeStoreServiceImpl.java:84) [classes/:na]
> 	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadKieSession(KnowledgeStoreServiceImpl.java:1) [classes/:na]
> 	at org.kie.internal.persistence.jpa.JPAKnowledgeService.loadStatefulKnowledgeSession(JPAKnowledgeService.java:130) [kie-internal-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> 	at org.drools.persistence.session.JpaPersistentStatefulSessionTest.testFromNodeWithModifiedCollection(JpaPersistentStatefulSessionTest.java:562) [test-classes/:na]
> ...
> Caused by: java.lang.NullPointerException: null
> 	at org.drools.core.reteoo.FromNode.createRightTuple(FromNode.java:152) ~[classes/:na]
> 	at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:96) ~[classes/:na]
> 	at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:49) ~[classes/:na]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:348) ~[classes/:na]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[classes/:na]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[classes/:na]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller$PBActivationsFilter.fireRNEAs(ProtobufInputMarshaller.java:813) ~[classes/:na]
> 	at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:258) ~[classes/:na]
> 	at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:199) ~[classes/:na]
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[classes/:na]
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288) ~[classes/:na]
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:499) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:476) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:250) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:157) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:116) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:1) ~[classes/:na]
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:83) ~[classes/:na]
> {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 issues at jboss.org  Tue Jan  7 04:25:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-370) Declarative Agenda control
 does not support all possible constraints
In-Reply-To: <JIRA.12527286.1386457535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527286.1386457535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527286.1386457535000.32287.1389086733864@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1042926|https://bugzilla.redhat.com/show_bug.cgi?id=1042926] from MODIFIED to ON_QA
                
> Declarative Agenda control does not support all possible constraints
> --------------------------------------------------------------------
>
>                 Key: DROOLS-370
>                 URL: https://issues.jboss.org/browse/DROOLS-370
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            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 issues at jboss.org  Tue Jan  7 04:27:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-381) KieRepository holds old
 KieModules forever potentially causing memory problems
In-Reply-To: <JIRA.12528063.1387278815000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528063.1387278815000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528063.1387278815000.32295.1389086852991@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1044007|https://bugzilla.redhat.com/show_bug.cgi?id=1044007] from MODIFIED to ON_QA
                
> KieRepository holds old KieModules forever potentially causing memory problems
> ------------------------------------------------------------------------------
>
>                 Key: DROOLS-381
>                 URL: https://issues.jboss.org/browse/DROOLS-381
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> KieRepository has an internal data structure where it store the KieModules deployed in it. At the moment those KieModules remain there indefinitely even if they are no longer useful and this could be a potential OutOfMemory cause.

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

From issues at jboss.org  Tue Jan  7 04:29:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 04:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32300.1389086973689@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2703:
--------------------------------------

Can you provide a test case?
                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 04:31:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 04:31:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-374) WM Corruption when events
 are modified - was Bug in the expiration offset calculation
In-Reply-To: <JIRA.12527702.1386773434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527702.1386773434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527702.1386773434000.32316.1389087093757@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1043481|https://bugzilla.redhat.com/show_bug.cgi?id=1043481] from MODIFIED to ON_QA
                
> WM Corruption when events are modified - was Bug in the expiration offset calculation 
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-374
>                 URL: https://issues.jboss.org/browse/DROOLS-374
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Thorsten Kunz
>            Assignee: Mario Fusco
>              Labels: event, expiration, fusion
>             Fix For: 6.0.1.Final
>
>         Attachments: drools-event-expiration-test.zip
>
>
> In some cases there seems to be a bug when an @expires annotation is set on an event class and it is not expired by the time set in the annotation but what time it is possibly matched in a sliding window.
> I'll attach a simple test case that demonstrates when the @expires annotation is 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 issues at jboss.org  Tue Jan  7 05:05:32 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 7 Jan 2014 05:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.32356.1389089132894@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger updated WFLY-2690:
----------------------------------

    Summary: JSP/JSPX tags don't work with Wildfly CR1  (was: JSP/JSPX tags doesn't work with Wildfly CR1)

    
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Tue Jan  7 05:15:34 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Tue, 7 Jan 2014 05:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32371.1389089734226@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz commented on WFLY-2703:
-------------------------------------

Hmmm I don't see an upload capability here and I will not go to fileshare or whatever for this.

Could offer a google doc link:
https://drive.google.com/file/d/0BzlJ1QQ-lJ2ZT0FrMF96dzlYN1U/edit?usp=sharing

This is hust a small "test.war".
Deploy and go to: http://localhost:8080/test/test.xhtml

Then the textfield uses Ajax, enter something and press return. I have set the Development mode and you will see a Javascript alert and the broken pipe error. If you change to an other mode, this bug will go away.



Cheers, Andr?
                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 05:19:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 05:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32375.1389089972821@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2703:
--------------------------------------

You can attach a file using More -> Attach File
                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 05:33:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 05:33:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-361) Incremental compilation
 requires to provide the list of modified files even if not necessary
In-Reply-To: <JIRA.12526643.1386000701000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526643.1386000701000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526643.1386000701000.32396.1389090812696@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1036807|https://bugzilla.redhat.com/show_bug.cgi?id=1036807] from ON_QA to VERIFIED
                
> Incremental compilation requires to provide the list of modified files even if not necessary
> --------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-361
>                 URL: https://issues.jboss.org/browse/DROOLS-361
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> Incremental compilation requires to provide the list of the modified files since the last compilation. However this could be error-prone and violates the DRY principle, because this list could be automatically calculated.

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

From issues at jboss.org  Tue Jan  7 05:35:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 05:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-360) Incremental compilation:
 Flawed for Rule Templates
In-Reply-To: <JIRA.12526621.1385991859000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526621.1385991859000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526621.1385991859000.32399.1389090932755@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1036842|https://bugzilla.redhat.com/show_bug.cgi?id=1036842] from ON_QA to VERIFIED
                
> Incremental compilation: Flawed for Rule Templates
> --------------------------------------------------
>
>                 Key: DROOLS-360
>                 URL: https://issues.jboss.org/browse/DROOLS-360
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Anstis
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> Incremental compilation does not add new messages when a Rule Template is updated from being valid to being invalid. Full build with valid Rule Template passes; but Incremental Compilation with updated (and invalid) Rule Template does not lead to any "added" messages. 
> Updating a Rule Template from invalid to valid does however work. Full build with invalid Rule Template correctly returns error messages and Incremental Compilation with updated (and valid) Rule Template does lead to error message being removed.
> Unit tests created (failing one @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 issues at jboss.org  Tue Jan  7 05:37:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 05:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree
 viewer does not work with timer and || operator.
In-Reply-To: <JIRA.12518034.1383664067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518034.1383664067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518034.1383664067000.32405.1389091053110@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1027120|https://bugzilla.redhat.com/show_bug.cgi?id=1027120] from ASSIGNED to MODIFIED
                
> Drools plugin Rete Tree viewer does not work with timer and || operator.
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-320
>                 URL: https://issues.jboss.org/browse/DROOLS-320
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>         Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>              Labels: drools, eclipse, plugin, rete, tree, view
>
> See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
> The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
> - the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException: [Rete(0)]
> - the '||' operator in the rule "Hello World-Or". This gives the error:
> Rete Tree Build Error!
> Reason:
> java.lang.NullPointerException: null
> This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).

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

From issues at jboss.org  Tue Jan  7 05:37:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 05:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-363) Incremental compilation
 fails with declared types
In-Reply-To: <JIRA.12526743.1386071298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526743.1386071298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526743.1386071298000.32408.1389091053211@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1037572|https://bugzilla.redhat.com/show_bug.cgi?id=1037572] from ON_QA to VERIFIED
                
> Incremental compilation fails with declared types
> -------------------------------------------------
>
>                 Key: DROOLS-363
>                 URL: https://issues.jboss.org/browse/DROOLS-363
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> Incremental compilation doesn't work if the newly added drl contains a declared type.

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

From issues at jboss.org  Tue Jan  7 05:43:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jan 2014 05:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from
 the internal thread pool should not do work stealing
In-Reply-To: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524440.1383823189000.32418.1389091412845@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1732:
--------------------------------

Picked solution 2
                
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1732
>                 URL: https://issues.jboss.org/browse/JGRP-1732
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns

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

From issues at jboss.org  Tue Jan  7 05:47:33 2014
From: issues at jboss.org (Rajeev kumar (JIRA))
Date: Tue, 7 Jan 2014 05:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-121) Empty directories under
 "tmp/vfs" keeps on growing between server restarts
In-Reply-To: <JIRA.12446867.1315934247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446867.1315934247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446867.1315934247000.32423.1389091653065@jira02.app.mwc.hst.phx2.redhat.com>


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

Rajeev kumar commented on WFLY-121:
-----------------------------------

Hi,

As this issue is working fine in WildFly CR8.0.0 CR1. Can we get fix for Jboss AS 7.1.3 version fix.

Thanks
                
> Empty directories under "tmp/vfs" keeps on growing between server restarts
> --------------------------------------------------------------------------
>
>                 Key: WFLY-121
>                 URL: https://issues.jboss.org/browse/WFLY-121
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>            Reporter: Ramesh Reddy
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha1
>
>
> When you have active deployment deployed to the server and you are restarting server for various reasons, the tmp/vfs keeps on growing with empty directories. It deletes the contents under the directory but not the directory itself.

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

From issues at jboss.org  Tue Jan  7 05:47:34 2014
From: issues at jboss.org (Rajeev kumar (JIRA))
Date: Tue, 7 Jan 2014 05:47:34 -0500 (EST)
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.32444.1389091654187@jira02.app.mwc.hst.phx2.redhat.com>


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

Rajeev kumar commented on WFLY-1547:
------------------------------------

Hi,

As this issue is working fine in WildFly CR8.0.0 CR1. Can we get fix for Jboss AS 7.1.3 version fix.

Thanks

                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    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 issues at jboss.org  Tue Jan  7 05:47:34 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Jan 2014 05:47:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM
 authentication does not work with httpd+JBossEAP6 if SPNEGO not available
In-Reply-To: <JIRA.12482678.1358326298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482678.1358326298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482678.1358326298000.32447.1389091654335@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated SECURITY-722:
--------------------------------------

    Fix Version/s: Negotiation_2_2_7

    
> SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available
> -------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-722
>                 URL: https://issues.jboss.org/browse/SECURITY-722
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_1
>         Environment: RHEL6, JBoss EAP 6
>            Reporter: flame liu
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_7
>
>
> I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated.
> After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out.

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

From issues at jboss.org  Tue Jan  7 05:55:32 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Tue, 7 Jan 2014 05:55:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2712) Possible NPE in
 RemoteDeployer from WS tests-integration
In-Reply-To: <JIRA.12528666.1389018040000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528666.1389018040000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528666.1389018040000.32461.1389092132800@jira02.app.mwc.hst.phx2.redhat.com>


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

Alessio Soldano commented on WFLY-2712:
---------------------------------------

Hi Rostislav,
this should be fixed to either check for null on line 305 too, or avoid checking it at all. The exception can actually be reproduced in the JBossWS testsuite only by direct usage of the JBossWSTestHelper#addHttpsConnector method. When relying on the JBossWSTestSetup (which is the common scenario), the invocation is actually performed only when a not null map parameter is provided.
                
> Possible NPE in RemoteDeployer from WS tests-integration
> --------------------------------------------------------
>
>                 Key: WFLY-2712
>                 URL: https://issues.jboss.org/browse/WFLY-2712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>
> https://github.com/rsvoboda/wildfly/blob/master/webservices/tests-integration/src/main/java/org/jboss/as/webservices/deployer/RemoteDeployer.java#L305  
> Possible NPE, check 'if (options != null)' is present only on line 284.
> Or is it intentional to throw exception ?

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

From issues at jboss.org  Tue Jan  7 06:05:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 06:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-367) Kie-ci doesn't try to access
 additional remote repositories declared in settings.xml
In-Reply-To: <JIRA.12527211.1386328527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527211.1386328527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527211.1386328527000.32483.1389092732918@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1039016|https://bugzilla.redhat.com/show_bug.cgi?id=1039016] from ASSIGNED to VERIFIED
                
> Kie-ci doesn't try to access additional remote repositories declared in settings.xml
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-367
>                 URL: https://issues.jboss.org/browse/DROOLS-367
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> In maven's settings.xml file it is possible to create additional profiles and declare additional remote repositories as in:
> {code}
>   <profiles>
>     <profile>
>       <id>guvnor-m2-profile</id>
>       <activation>
>         <activeByDefault>true</activeByDefault>
>       </activation>
>       <repositories>
>         <repository>
>           <id>guvnor-m2-repo</id>
>           <name>Guvnor M2 Repo</name>
>           <url>http://localhost:8080/m-kie-drools-wb-distribution-wars-6.0.0.Final-jboss-as7.0/maven2</url>
>         </repository>
>       </repositories>
>     </profile>
>   </profiles>
> {code}
> However kie-ci doesn't try to access this further repositories (as it should) when resolving a kjar.

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

From issues at jboss.org  Tue Jan  7 06:07:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Tue, 7 Jan 2014 06:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32491.1389092853219@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz updated WFLY-2703:
--------------------------------

    Attachment: test.war


deploy this war.
call http://localhost:8080/test/test.xhtml

enter some text and press return -> javascript alert appears shortly, broken pipe exception

enter some text and press tab for focus lost - works without problems.


here you can also see the difference with using umlauts...ajax OK, return not.  (i know, applay the filter trick with CDI Filter as last)
                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>         Attachments: test.war
>
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 06:09:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Tue, 7 Jan 2014 06:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32499.1389092973140@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz commented on WFLY-2703:
-------------------------------------

sry didn't see this feature, thanks.

have applied file.

i see this broken pipe now also at other places, i think we had this problem with tomcat too some years ago and then the broken pipe exceptions have been removed at some time, didn't work.

for instance I get also this for conversations, if a page needs to long, especially with Ajax.


12:03:02,410 WARN  [org.jboss.weld.Conversation] (default task-14) WELD-000315: Failed to acquire conversation lock in 1,000 ms for Conversation with id: 2
12:03:02,643 ERROR [io.undertow.request] (default task-13) Blocking request failed HttpServerExchange{ POST /xrepository/Inhaltverwaltung/Suche/XoevVorhaben.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: java.io.IOException: Broken pipe
	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)


No javax.enterprise.context.BusyConversationException is triggered in the global JSF exception handler - another different bug :/
                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>         Attachments: test.war
>
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 06:31:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 06:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32568.1389094292728@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2703:
--------------------------------------

I tried it out and all I seem to get is  javax.faces.application.ViewExpiredException: viewId:/test.xhtml - View /test.xhtml could not be restored.

                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>         Attachments: test.war
>
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 06:45:32 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Tue, 7 Jan 2014 06:45:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2703) Undertow Broken pipe with
 JSFs f:ajax and h:inputText
In-Reply-To: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528536.1388671551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528536.1388671551000.32600.1389095132768@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Pankraz commented on WFLY-2703:
-------------------------------------

But this exception would also be wrong, right? ;)
I cannot do much more here...I deployed this war to yesterdays build from git-master and I get the described behaviour.

After some more tests:
Broken pipes appear at many places in the log, especially together with Ajax.
The described cases here (development-mode and return or after blocked conversation exception in ajax-call) are just two examples of a bigger problem I think.
I don't think this exception-log makes much sense. Modern web apps use lots of Ajax, some of this triggered requests might take a second or more, if the user leaves the page in this time (e.g. submit) -> exception

Don't know where the Javascript-Alert comes from thought, application server debugging time is restricted at work ;)

                
> Undertow Broken pipe with JSFs f:ajax and h:inputText
> -----------------------------------------------------
>
>                 Key: WFLY-2703
>                 URL: https://issues.jboss.org/browse/WFLY-2703
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux, JDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>         Attachments: test.war
>
>
> Combine input text with default ajax event (leave):
> <h:form id="inhaltSearch">
> <h:inputText id="contentname" size="30"
> 	value="#{contentList.content.searchTerms}">
> 	<f:ajax render=":inhaltSearch" />
> </h:inputText>
> </h:form>
> Enter value and press "Enter" (Tab works).
> A short Javascript alert appears and vanishes again.
> Stacktrace in Server:
> 14:57:59,441 ERROR [io.undertow.request] (default task-49) Blocking request failed HttpServerExchange{ POST /.../Suche.xhtml}: java.lang.RuntimeException: java.io.IOException: Broken pipe
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:513)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: Broken pipe
> 	at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_45]
> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) [rt.jar:1.7.0_45]
> 	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150) [xnio-nio-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:484)
> 	at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:189)
> 	at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:117)
> 	at org.xnio.channels.Channels.flushBlocking(Channels.java:63) [xnio-api-3.1.0.CR7.jar:3.1.0.CR7]
> 	at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:510)
> 	... 9 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 issues at jboss.org  Tue Jan  7 06:57:33 2014
From: issues at jboss.org (Adriano Scheffer (JIRA))
Date: Tue, 7 Jan 2014 06:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2682) Conversation identifier does
 not get incremented
In-Reply-To: <JIRA.12528381.1387815561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528381.1387815561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528381.1387815561000.32630.1389095853101@jira02.app.mwc.hst.phx2.redhat.com>


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

Adriano Scheffer commented on WFLY-2682:
----------------------------------------

I think it is a problem releated to the session creation, but I couldn't reproduce it all the time. If I find out more information I'll post here.
                
> Conversation identifier does not get incremented
> ------------------------------------------------
>
>                 Key: WFLY-2682
>                 URL: https://issues.jboss.org/browse/WFLY-2682
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows 7
>            Reporter: Adriano Scheffer
>            Assignee: Stuart Douglas
>
> The conversation id is not getting incremented when I open another browser tab. Conversely, this problems was not happening in 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 issues at jboss.org  Tue Jan  7 08:17:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 08:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.32920.1389100653076@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tom Fonteyne <tfonteyn at redhat.com> changed the Status of [bug 1047519|https://bugzilla.redhat.com/show_bug.cgi?id=1047519] from ASSIGNED to MODIFIED
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Tue Jan  7 08:19:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 08:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.32923.1389100772948@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tom Fonteyne <tfonteyn at redhat.com> changed the Status of [bug 1047536|https://bugzilla.redhat.com/show_bug.cgi?id=1047536] from ASSIGNED to MODIFIED
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Tue Jan  7 08:25:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 08:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS /
 Hibernate JPA integration
In-Reply-To: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526628.1385994740000.32953.1389101133226@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1040733|https://bugzilla.redhat.com/show_bug.cgi?id=1040733] from POST to MODIFIED
                
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
>                 Key: WFLY-2593
>                 URL: https://issues.jboss.org/browse/WFLY-2593
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: No Release
>         Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
>            Reporter: Michael Kozak
>            Assignee: Scott Marlow
>            Priority: Critical
>             Fix For: No Release
>
>         Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA. 
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.

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

From issues at jboss.org  Tue Jan  7 08:27:32 2014
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 7 Jan 2014 08:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2712) Possible NPE in
 RemoteDeployer from WS tests-integration
In-Reply-To: <JIRA.12528666.1389018040000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528666.1389018040000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528666.1389018040000.32959.1389101252984@jira02.app.mwc.hst.phx2.redhat.com>


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

Rostislav Svoboda commented on WFLY-2712:
-----------------------------------------

Check on line 305 should be fine. I'll send PR for it.
                
> Possible NPE in RemoteDeployer from WS tests-integration
> --------------------------------------------------------
>
>                 Key: WFLY-2712
>                 URL: https://issues.jboss.org/browse/WFLY-2712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>
> https://github.com/rsvoboda/wildfly/blob/master/webservices/tests-integration/src/main/java/org/jboss/as/webservices/deployer/RemoteDeployer.java#L305  
> Possible NPE, check 'if (options != null)' is present only on line 284.
> Or is it intentional to throw exception ?

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

From issues at jboss.org  Tue Jan  7 08:27:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 08:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2633) Cannot use deployments with
 same runtime-name in a domain
In-Reply-To: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527605.1386720363000.32968.1389101253362@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1040621|https://bugzilla.redhat.com/show_bug.cgi?id=1040621] from POST to MODIFIED
                
> Cannot use deployments with same runtime-name in a domain
> ---------------------------------------------------------
>
>                 Key: WFLY-2633
>                 URL: https://issues.jboss.org/browse/WFLY-2633
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The check for duplicate runtime-name in a server group on startup is too aggressive.  It is incorrectly throwing an error on startup if there are any duplicate runtime-names in the whole domain, instead of just in a single server group.
> Steps to Reproduce:
> 1.  Start a single HC/DC
> 2.  deploy --name=foo1 --runtime-name=bar --disabled testfile
> 3.  deploy --name=foo2 --runtime-name=bar --disabled testfile
> 4.  restart the DC/HC
> Actual results:
> JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> ...
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9]
> ...
> Message: JBAS014664: An element of this type named 'bar' has already been declared
> Expected results:
> No errors

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

From issues at jboss.org  Tue Jan  7 08:29:32 2014
From: issues at jboss.org (Matus Zamborsky (JIRA))
Date: Tue, 7 Jan 2014 08:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.32975.1389101372861@jira02.app.mwc.hst.phx2.redhat.com>


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

Matus Zamborsky commented on WFLY-2690:
---------------------------------------

Jozef, do you mean, that the method asString() from Identiefier should be unique for every type ? Or there is something else which should be taken care of. If it's the first option, we can add Integer.toHexString(System.identityHashCode(clazz)) to the identifier string. 

The problem is that Integer.toHexString(System.identityHashCode(clazz)) does not necessary need to be unique by java spec. Another, slightly more complicated solution will be to use a static Map from Class object to unique generated identifier. As a source we can use static Long number incremented and returned in synchronized method, so every invocation will return new unique number. Even better, if we use the classloader of the clazz as there can't be two classes with same name in one classloader.
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Tue Jan  7 08:45:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 08:45:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.32989.1389102332931@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1039676|https://bugzilla.redhat.com/show_bug.cgi?id=1039676] from ASSIGNED to MODIFIED
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Tue Jan  7 09:04:33 2014
From: issues at jboss.org (Dirk Weil (JIRA))
Date: Tue, 7 Jan 2014 09:04:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2717) Exceptions returnd from
 remote ejb calls create ClassCastException
In-Reply-To: <JIRA.12528737.1389103428884@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528737.1389103428884@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528737.1389103428884.33018.1389103473956@jira02.app.mwc.hst.phx2.redhat.com>

Dirk Weil created WFLY-2717:
-------------------------------

             Summary: Exceptions returnd from remote ejb calls create ClassCastException
                 Key: WFLY-2717
                 URL: https://issues.jboss.org/browse/WFLY-2717
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Remoting
    Affects Versions: 8.0.0.CR1
         Environment: Windows, Java 1.7.0_40
            Reporter: Dirk Weil
            Assignee: David Lloyd


An exception thrown by an ejb is not marshalled correctly to the calling remote client. Instead a ClassCastException is raised.

Stack trace on client:
java.lang.AssertionError: 
Expected: class java.lang.UnsupportedOperationException as (in)directly causing exception
     but: was <java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String>
Stacktrace was: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
	at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:55)
	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:82)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
	at com.sun.proxy.$Proxy6.getException(Unknown Source)
	at de.gedoplan.beantrial.wildflyejbremote.DemoTest.testGetException(DemoTest.java:60)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	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)

	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at org.junit.Assert.assertThat(Assert.java:832)
	at org.junit.rules.ExpectedException.handleException(ExpectedException.java:198)
	at org.junit.rules.ExpectedException.access$500(ExpectedException.java:85)
	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:177)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	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)

Stack trace on server:
14:50:47,688 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component DemoBean for method public abstract void de.gedoplan.beantrial.wi
ldflyejbremote.Demo.getException(): javax.ejb.EJBException: java.lang.UnsupportedOperationException: Not implemented
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.CR1.jar:8.0
.0.CR1]
        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.CR1.jar:8
.0.0.CR1]
        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.CR1.jar:8.0.0.CR1]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        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.CR1.jar:8.0.0.CR1]
        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.CR1.jar:8.0.0.CR1]
        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.CR1.jar:8.0.0.CR1]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
        at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40]
        at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40]
        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]
        at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.UnsupportedOperationException: Not implemented
        at de.gedoplan.beantrial.wildflyejbremote.DemoBean.getException(DemoBean.java:17) [wildfly-ejbremote-demo.jar:]
        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.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
        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.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
        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.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.1.Final.jar:2013-1
2-03 09:59]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
        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.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
        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.CR1.jar:8.0.0.CR1]
        ... 39 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 issues at jboss.org  Tue Jan  7 09:12:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 09:12:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2616) SEVERE is not an available
 logging level in the CLI
In-Reply-To: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527159.1386289598000.33043.1389103953562@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1038862|https://bugzilla.redhat.com/show_bug.cgi?id=1038862] from POST to MODIFIED
                
> SEVERE is not an available logging level in the CLI
> ---------------------------------------------------
>
>                 Key: WFLY-2616
>                 URL: https://issues.jboss.org/browse/WFLY-2616
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Kyle Lape
>            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 issues at jboss.org  Tue Jan  7 09:34:32 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Tue, 7 Jan 2014 09:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2718) Deploying a pure InFlow rar
 as module drive fail
In-Reply-To: <JIRA.12528739.1389105267892@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528739.1389105267892@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528739.1389105267892.33075.1389105272726@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-2718:
-------------------------------------

             Summary: Deploying a pure InFlow rar as module drive fail
                 Key: WFLY-2718
                 URL: https://issues.jboss.org/browse/WFLY-2718
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.CR1
            Reporter: Stefano Maestri
            Assignee: Jesper Pedersen
             Fix For: 8.0.0.Final


Deploying a pure InFlow rar as module drive to this exception:


13:24:35,436 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ra.deployment."org.wildfly.mail.ra:main": org.jboss.msc.service.StartException in service jboss.ra.deployment."org.wildfly.mail.ra:main": org.jboss.msc.service.DuplicateServiceException: Service jboss.ra."org.wildfly.mail.ra:main" is already registered
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:137)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	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.ra."org.wildfly.mail.ra:main" is already registered
	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:131)
	... 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 issues at jboss.org  Tue Jan  7 09:36:32 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Tue, 7 Jan 2014 09:36:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2718) Deploying a pure InFlow rar
 as module drive fail
In-Reply-To: <JIRA.12528739.1389105267000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528739.1389105267000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528739.1389105267000.33080.1389105392996@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned WFLY-2718:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> Deploying a pure InFlow rar as module drive fail
> ------------------------------------------------
>
>                 Key: WFLY-2718
>                 URL: https://issues.jboss.org/browse/WFLY-2718
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.Final
>
>
> Deploying a pure InFlow rar as module drive to this exception:
> 13:24:35,436 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ra.deployment."org.wildfly.mail.ra:main": org.jboss.msc.service.StartException in service jboss.ra.deployment."org.wildfly.mail.ra:main": org.jboss.msc.service.DuplicateServiceException: Service jboss.ra."org.wildfly.mail.ra:main" is already registered
> 	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:137)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	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.ra."org.wildfly.mail.ra:main" is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:131)
> 	... 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 issues at jboss.org  Tue Jan  7 10:08:34 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jan 2014 10:08:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2685)
 java.lang.IllegalStateException: Collection element (many-to-many) table
 alias cannot be empty"}}
In-Reply-To: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528397.1387877400000.33187.1389107314419@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2685:
------------------------------------

Could you create a Hibernate Jira for this?  The link is https://hibernate.atlassian.net/browse/HHH

Please let me know what the Hibernate jira number is when you create it.


                
> java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2685
>                 URL: https://issues.jboss.org/browse/WFLY-2685
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: Mac OS 10.9
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> wildfly-8.0.0.CR1
>            Reporter: Luca Masini
>            Assignee: Scott Marlow
>         Attachments: test-case-jpa.zip
>
>
> I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
> In practice mapping an ElementCollection like this:
>     @ElementCollection(fetch = FetchType.EAGER)
>     @CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
>     @MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
>     Map<ParameterRegistry, String> previewQueryParams;
> I got an exception during deployment:
> Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 8 more
> I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
> The same test-case work under
> WF 8.0.0.Beta1
> Glassfish 4
> WebLogic 12c

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

From issues at jboss.org  Tue Jan  7 10:22:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 7 Jan 2014 10:22:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.33209.1389108153663@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2690:
---------------------------------------

Two Identifiers may only be equal only if their asString() results are equal. In addition, the ID has to be deterministic - each node of a cluster has to use the same id for a given type.
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Tue Jan  7 10:36:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 10:36:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.33242.1389108994902@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1047519|https://bugzilla.redhat.com/show_bug.cgi?id=1047519] from MODIFIED to POST
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Tue Jan  7 11:04:32 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 7 Jan 2014 11:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-780) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528745.1389110556228@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528745.1389110556228@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528745.1389110556228.33276.1389110672996@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created SECURITY-780:
-------------------------------------

             Summary: EXTC with timeout not properly detected by loadPassword utility in login modules
                 Key: SECURITY-780
                 URL: https://issues.jboss.org/browse/SECURITY-780
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: PicketBox_4_0_20.Beta2
            Reporter: Peter Skopek
            Assignee: Peter Skopek


Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
Example: {EXTC:1000}/usr/bin/getmysecretpwd


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

From issues at jboss.org  Tue Jan  7 11:10:33 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 7 Jan 2014 11:10:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-780) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528745.1389110556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528745.1389110556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528745.1389110556000.33300.1389111033039@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek resolved SECURITY-780.
-----------------------------------

    Resolution: Done

    
> EXTC with timeout not properly detected by loadPassword utility in login modules
> --------------------------------------------------------------------------------
>
>                 Key: SECURITY-780
>                 URL: https://issues.jboss.org/browse/SECURITY-780
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_20.Beta2
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>
> Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
> Example: {EXTC:1000}/usr/bin/getmysecretpwd

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

From issues at jboss.org  Tue Jan  7 11:30:32 2014
From: issues at jboss.org (Luca Masini (JIRA))
Date: Tue, 7 Jan 2014 11:30:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2685)
 java.lang.IllegalStateException: Collection element (many-to-many) table
 alias cannot be empty"}}
In-Reply-To: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528397.1387877400000.33335.1389112232786@jira02.app.mwc.hst.phx2.redhat.com>


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

Luca Masini edited comment on WFLY-2685 at 1/7/14 11:29 AM:
------------------------------------------------------------

mvn install and then deploy on WF 8.0.0.CR1
                
      was (Author: luca.masini):
    mvn install and the deploy on WF 8
                  
> java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2685
>                 URL: https://issues.jboss.org/browse/WFLY-2685
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: Mac OS 10.9
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> wildfly-8.0.0.CR1
>            Reporter: Luca Masini
>            Assignee: Scott Marlow
>         Attachments: test-case-jpa.zip
>
>
> I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
> In practice mapping an ElementCollection like this:
>     @ElementCollection(fetch = FetchType.EAGER)
>     @CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
>     @MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
>     Map<ParameterRegistry, String> previewQueryParams;
> I got an exception during deployment:
> Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 8 more
> I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
> The same test-case work under
> WF 8.0.0.Beta1
> Glassfish 4
> WebLogic 12c

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

From issues at jboss.org  Tue Jan  7 11:30:32 2014
From: issues at jboss.org (Luca Masini (JIRA))
Date: Tue, 7 Jan 2014 11:30:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2685)
 java.lang.IllegalStateException: Collection element (many-to-many) table
 alias cannot be empty"}}
In-Reply-To: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528397.1387877400000.33337.1389112232883@jira02.app.mwc.hst.phx2.redhat.com>


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

Luca Masini commented on WFLY-2685:
-----------------------------------

https://hibernate.atlassian.net/browse/HHH-8839
                
> java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2685
>                 URL: https://issues.jboss.org/browse/WFLY-2685
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: Mac OS 10.9
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> wildfly-8.0.0.CR1
>            Reporter: Luca Masini
>            Assignee: Scott Marlow
>         Attachments: test-case-jpa.zip
>
>
> I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
> In practice mapping an ElementCollection like this:
>     @ElementCollection(fetch = FetchType.EAGER)
>     @CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
>     @MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
>     Map<ParameterRegistry, String> previewQueryParams;
> I got an exception during deployment:
> Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 8 more
> I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
> The same test-case work under
> WF 8.0.0.Beta1
> Glassfish 4
> WebLogic 12c

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

From issues at jboss.org  Tue Jan  7 12:02:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 12:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-381) KieRepository holds old
 KieModules forever potentially causing memory problems
In-Reply-To: <JIRA.12528063.1387278815000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528063.1387278815000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528063.1387278815000.33403.1389114153126@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1044007|https://bugzilla.redhat.com/show_bug.cgi?id=1044007] from ON_QA to VERIFIED
                
> KieRepository holds old KieModules forever potentially causing memory problems
> ------------------------------------------------------------------------------
>
>                 Key: DROOLS-381
>                 URL: https://issues.jboss.org/browse/DROOLS-381
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> KieRepository has an internal data structure where it store the KieModules deployed in it. At the moment those KieModules remain there indefinitely even if they are no longer useful and this could be a potential OutOfMemory cause.

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

From issues at jboss.org  Tue Jan  7 12:14:33 2014
From: issues at jboss.org (Robert Panzer (JIRA))
Date: Tue, 7 Jan 2014 12:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-370) Deployment of a war with 2
 web-fragments both containing ejb-local-refs fails
In-Reply-To: <JIRA.12528756.1389114759515@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528756.1389114759515@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528756.1389114759515.33420.1389114873449@jira02.app.mwc.hst.phx2.redhat.com>

Robert Panzer created JBMETA-370:
------------------------------------

             Summary: Deployment of a war with 2 web-fragments both containing ejb-local-refs fails
                 Key: JBMETA-370
                 URL: https://issues.jboss.org/browse/JBMETA-370
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common
         Environment: Win7, Oracle JDK 1.7.0_45, Wildfly 8.0.0-CR1
            Reporter: Robert Panzer


When trying to deploy a WAR containing two web-fragments both containing ejb-local-refs the deployment fails with this error message:

17:54:24,669 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "testear.ear" (runtime-name: "testear.ear")
17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "testwar.war")
17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "ejbjar.jar")
17:55:55,538 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartExcep
tion in service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
        at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:294)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        ... 5 more
Caused by: java.lang.IllegalArgumentException: Null administeredObjects
        at org.jboss.metadata.javaee.spec.RemoteEnvironmentRefsGroupMetaData.setAdministeredObjects(RemoteEnvironmentRefsGroupMetaData.java:431)
        at org.jboss.metadata.merge.javaee.spec.RemoteEnvironmentRefsGroupMetaDataMerger.augment(RemoteEnvironmentRefsGroupMetaDataMerger.java:337)
        at org.jboss.metadata.merge.javaee.spec.EnvironmentRefsGroupMetaDataMerger.augment(EnvironmentRefsGroupMetaDataMerger.java:71)
        at org.jboss.metadata.merge.web.spec.WebCommonMetaDataMerger.augment(WebCommonMetaDataMerger.java:383)
        at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:292)
        ... 6 more

17:55:55,621 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "testear.ear")]) - failure descr
iption: {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"testear.ear\".\"testwar.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"testear.ear\"
.\"testwar.war\".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment \"testwar.war\" of deployment \"testear.ear\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
    Caused by: java.lang.IllegalArgumentException: Null administeredObjects"}}
17:55:55,881 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "testear.ear" (runtime-name : "testear.ear")
17:55:55,882 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."testear
.ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"

There seems to be an error in the class RemoteEnvironmentRefsGroupMetaDataMerger because it calls dest.setAdministeredObjects() during augmentation even if the fragment does not contain administered objects (but entries in the ENC so that the merger is called.)

I created a test application that shows the problem. You can find it at https://github.com/robertpanzer/webfragmenttest.git

I can also provide a PR.

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

From issues at jboss.org  Tue Jan  7 12:20:33 2014
From: issues at jboss.org (Robert Panzer (JIRA))
Date: Tue, 7 Jan 2014 12:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-370) Deployment of a war with 2
 web-fragments both containing ejb-local-refs fails
In-Reply-To: <JIRA.12528756.1389114759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528756.1389114759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528756.1389114759000.33431.1389115233413@jira02.app.mwc.hst.phx2.redhat.com>


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

Robert Panzer updated JBMETA-370:
---------------------------------

    Git Pull Request: https://github.com/jboss/metadata/pull/56

    
> Deployment of a war with 2 web-fragments both containing ejb-local-refs fails
> -----------------------------------------------------------------------------
>
>                 Key: JBMETA-370
>                 URL: https://issues.jboss.org/browse/JBMETA-370
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>         Environment: Win7, Oracle JDK 1.7.0_45, Wildfly 8.0.0-CR1
>            Reporter: Robert Panzer
>
> When trying to deploy a WAR containing two web-fragments both containing ejb-local-refs the deployment fails with this error message:
> 17:54:24,669 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "testear.ear" (runtime-name: "testear.ear")
> 17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "testwar.war")
> 17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "ejbjar.jar")
> 17:55:55,538 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartExcep
> tion in service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
>         at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:294)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         ... 5 more
> Caused by: java.lang.IllegalArgumentException: Null administeredObjects
>         at org.jboss.metadata.javaee.spec.RemoteEnvironmentRefsGroupMetaData.setAdministeredObjects(RemoteEnvironmentRefsGroupMetaData.java:431)
>         at org.jboss.metadata.merge.javaee.spec.RemoteEnvironmentRefsGroupMetaDataMerger.augment(RemoteEnvironmentRefsGroupMetaDataMerger.java:337)
>         at org.jboss.metadata.merge.javaee.spec.EnvironmentRefsGroupMetaDataMerger.augment(EnvironmentRefsGroupMetaDataMerger.java:71)
>         at org.jboss.metadata.merge.web.spec.WebCommonMetaDataMerger.augment(WebCommonMetaDataMerger.java:383)
>         at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:292)
>         ... 6 more
> 17:55:55,621 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "testear.ear")]) - failure descr
> iption: {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"testear.ear\".\"testwar.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"testear.ear\"
> .\"testwar.war\".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment \"testwar.war\" of deployment \"testear.ear\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
>     Caused by: java.lang.IllegalArgumentException: Null administeredObjects"}}
> 17:55:55,881 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "testear.ear" (runtime-name : "testear.ear")
> 17:55:55,882 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."testear
> .ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
> There seems to be an error in the class RemoteEnvironmentRefsGroupMetaDataMerger because it calls dest.setAdministeredObjects() during augmentation even if the fragment does not contain administered objects (but entries in the ENC so that the merger is called.)
> I created a test application that shows the problem. You can find it at https://github.com/robertpanzer/webfragmenttest.git
> I can also provide a PR.

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

From issues at jboss.org  Tue Jan  7 13:48:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jan 2014 13:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2685)
 java.lang.IllegalStateException: Collection element (many-to-many) table
 alias cannot be empty"}}
In-Reply-To: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528397.1387877400000.33660.1389120513099@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2685:
------------------------------------

Excellent, thanks Luca.  I'll close this jira, as HHH-8839 should be enough to report the issue.
                
> java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2685
>                 URL: https://issues.jboss.org/browse/WFLY-2685
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: Mac OS 10.9
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> wildfly-8.0.0.CR1
>            Reporter: Luca Masini
>            Assignee: Scott Marlow
>         Attachments: test-case-jpa.zip
>
>
> I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
> In practice mapping an ElementCollection like this:
>     @ElementCollection(fetch = FetchType.EAGER)
>     @CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
>     @MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
>     Map<ParameterRegistry, String> previewQueryParams;
> I got an exception during deployment:
> Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 8 more
> I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
> The same test-case work under
> WF 8.0.0.Beta1
> Glassfish 4
> WebLogic 12c

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

From issues at jboss.org  Tue Jan  7 13:48:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jan 2014 13:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2685)
 java.lang.IllegalStateException: Collection element (many-to-many) table
 alias cannot be empty"}}
In-Reply-To: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528397.1387877400000.33665.1389120513191@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow resolved WFLY-2685.
--------------------------------

    Resolution: Duplicate Issue

    
> java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2685
>                 URL: https://issues.jboss.org/browse/WFLY-2685
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: Mac OS 10.9
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> wildfly-8.0.0.CR1
>            Reporter: Luca Masini
>            Assignee: Scott Marlow
>         Attachments: test-case-jpa.zip
>
>
> I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
> In practice mapping an ElementCollection like this:
>     @ElementCollection(fetch = FetchType.EAGER)
>     @CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
>     @MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
>     Map<ParameterRegistry, String> previewQueryParams;
> I got an exception during deployment:
> Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 8 more
> I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
> The same test-case work under
> WF 8.0.0.Beta1
> Glassfish 4
> WebLogic 12c

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

From issues at jboss.org  Tue Jan  7 13:48:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jan 2014 13:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2685)
 java.lang.IllegalStateException: Collection element (many-to-many) table
 alias cannot be empty"}}
In-Reply-To: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528397.1387877400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528397.1387877400000.33668.1389120513248@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow closed WFLY-2685.
------------------------------


    
> java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2685
>                 URL: https://issues.jboss.org/browse/WFLY-2685
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: Mac OS 10.9
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> wildfly-8.0.0.CR1
>            Reporter: Luca Masini
>            Assignee: Scott Marlow
>         Attachments: test-case-jpa.zip
>
>
> I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
> In practice mapping an ElementCollection like this:
>     @ElementCollection(fetch = FetchType.EAGER)
>     @CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
>     @MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
>     Map<ParameterRegistry, String> previewQueryParams;
> I got an exception during deployment:
> Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 8 more
> I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
> The same test-case work under
> WF 8.0.0.Beta1
> Glassfish 4
> WebLogic 12c

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

From issues at jboss.org  Tue Jan  7 14:02:33 2014
From: issues at jboss.org (James Bodkin (JIRA))
Date: Tue, 7 Jan 2014 14:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2719) NullPointerException on first
 request after deployment using beans.xml
In-Reply-To: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528793.1389121287000.33693.1389121353487@jira02.app.mwc.hst.phx2.redhat.com>


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

James Bodkin updated WFLY-2719:
-------------------------------

    Attachment: dew.zip


Source Code for Application
                
> NullPointerException on first request after deployment using beans.xml
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2719
>                 URL: https://issues.jboss.org/browse/WFLY-2719
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: James Bodkin
>            Assignee: Stuart Douglas
>            Priority: Minor
>         Attachments: dew.zip
>
>
> A NullPointerException occurs on the first request to the WildFly AS if the war package already exists and has been deployed via maven on both occasions causing an 500 Internal Server Error on the client.
> Removing the beans.xml from WEB-INF stops the error from occurring but services aren't injected.
> 02:36:11,177 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
> 	at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
> 	at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
> 	at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
> 	at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
> 	at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
> 	at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
> 	at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
> 	at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
> 	at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
> 	at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:46)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.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 issues at jboss.org  Tue Jan  7 14:02:33 2014
From: issues at jboss.org (James Bodkin (JIRA))
Date: Tue, 7 Jan 2014 14:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2719) NullPointerException on first
 request after deployment using beans.xml
In-Reply-To: <JIRA.12528793.1389121287817@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528793.1389121287817@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528793.1389121287817.33691.1389121353456@jira02.app.mwc.hst.phx2.redhat.com>

James Bodkin created WFLY-2719:
----------------------------------

             Summary: NullPointerException on first request after deployment using beans.xml
                 Key: WFLY-2719
                 URL: https://issues.jboss.org/browse/WFLY-2719
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: James Bodkin
            Assignee: Stuart Douglas
            Priority: Minor
         Attachments: dew.zip

A NullPointerException occurs on the first request to the WildFly AS if the war package already exists and has been deployed via maven on both occasions causing an 500 Internal Server Error on the client.

Removing the beans.xml from WEB-INF stops the error from occurring but services aren't injected.

02:36:11,177 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
	at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
	at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
	at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
	at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
	at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
	at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
	at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
	at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
	at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
	at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:46)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.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 issues at jboss.org  Tue Jan  7 14:04:32 2014
From: issues at jboss.org (James Bodkin (JIRA))
Date: Tue, 7 Jan 2014 14:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2719) NullPointerException on first
 request after deployment using beans.xml
In-Reply-To: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528793.1389121287000.33699.1389121472671@jira02.app.mwc.hst.phx2.redhat.com>


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

James Bodkin commented on WFLY-2719:
------------------------------------

I've attached the source code of the project that is causing the issue.
                
> NullPointerException on first request after deployment using beans.xml
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2719
>                 URL: https://issues.jboss.org/browse/WFLY-2719
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: James Bodkin
>            Assignee: Stuart Douglas
>            Priority: Minor
>         Attachments: dew.zip
>
>
> A NullPointerException occurs on the first request to the WildFly AS if the war package already exists and has been deployed via maven on both occasions causing an 500 Internal Server Error on the client.
> Removing the beans.xml from WEB-INF stops the error from occurring but services aren't injected.
> 02:36:11,177 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
> 	at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
> 	at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
> 	at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
> 	at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
> 	at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
> 	at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
> 	at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
> 	at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
> 	at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
> 	at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:46)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.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 issues at jboss.org  Tue Jan  7 14:22:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 14:22:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2716) Redeploy of a WAR results in
 ClassLoader leak when a logging-profile is enabled
In-Reply-To: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528700.1389071367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528700.1389071367000.33721.1389122553746@jira02.app.mwc.hst.phx2.redhat.com>


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

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

James Perkins <jperkins at redhat.com> changed the Status of [bug 1049138|https://bugzilla.redhat.com/show_bug.cgi?id=1049138] from NEW to CLOSED
                
> Redeploy of a WAR results in ClassLoader leak when a logging-profile is enabled
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2716
>                 URL: https://issues.jboss.org/browse/WFLY-2716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>         Environment: EAP 6.1.0 and EAP 6.2.0 as well.
>            Reporter: Osamu Nagano
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> Web app's ModuleClassLoader is not released even after its undeployment.  It seems {{contextMap}} of {{org.jboss.logmanager.ClassLoaderLogContextSelector}} object is holding the class loader's reference.  If no logging-profile is configured, it doesn't leak.

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

From issues at jboss.org  Tue Jan  7 15:16:35 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jan 2014 15:16:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2504) add lazy xpc inheritance to
 handle legacy case,
 remote client with UserTransaction fails on 2nd SFSB invocation when using
 extended persistence context
In-Reply-To: <JIRA.12524993.1384351632000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524993.1384351632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524993.1384351632000.33813.1389125795692@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2504:
-------------------------------

    Description: 
AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans (SFSB1+SFSB2) in a started user transaction (UT1).  Each of the stateful beans reference the same extended persistence context by name.  In AS5, both stateful beans will share the same extended persistence unit context but on AS7/WF8, each bean has its own extended persistence unit context.  Having both XPCS involved in the same user transaction, causes an (EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it...) error to be thrown.

On AS7/WF8, Allow the beans invoked in the same transaction, to share the same persistence context.  

One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).

Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.

Some of the AS5 code is pasted below for easy reference.

{code}
public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
{
   private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);

   public String getName()
   {
      return this.getClass().getName();
   }

   public Object invoke(Invocation invocation) throws Throwable
   {
      log.debug("++++ LongLivedSessionPropagationInterceptor");
      StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
      StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();

      Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
      if (extendedPCs == null || extendedPCs.size() == 0)
      {
         return invocation.invokeNext();
      }

      TransactionManager tm = TxUtil.getTransactionManager();
      if (tm.getTransaction() != null)
      {
         for (String kernelname : extendedPCs.keySet())
         {
            EntityManager manager = extendedPCs.get(kernelname);
            ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
            factory.registerExtendedWithTransaction(manager);
         }
      }
      return invocation.invokeNext();
   }
}
{code}

{code}
public class EJB3XPCResolver implements XPCResolver
{
   private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
   /**
    * Query the current stateful bean contexts for the specified XPC.
    */
   public EntityManager getExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;

         em = beanContext.getExtendedPersistenceContext(kernelName);
         if (em != null) {
            log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
            return em;
         }
         /**
          * Look for XPC in current bean set.
          */
         log.info("looking for existing XPC with scoped pu name=" + kernelName);

         List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
         for( StatefulBeanContext bc : beanContexts)
         {
            em = bc.getExtendedPersistenceContext(kernelName);
            if (em != null) {
               log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
               //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
               beanContext.addExtendedPersistenceContext(kernelName, em);
               return em;
            }
            log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
         }
      }
      log.info("XPC not found scoped, search done, pu name=" + kernelName);
      return null;
   }

   @Override
   public EntityManager createExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;
         ManagedEntityManagerFactory factory=
            ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
         if (factory != null)
         {
            em = factory.createEntityManager();
            if (em != null)
            {
               beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
               log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
               /**
                * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
                *
                */

//               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
//               for( StatefulBeanContext bc : beanContexts)
//               {
//                  bc.addExtendedPersistenceContext(kernelName, em);
//               }
            }
         }

         return em;
      }
      return null;
   }
}
{code}

{code}
public class ManagedEntityManagerFactoryHelper
{
   public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
   {
      PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
      if(pu != null)
         return pu.getManagedFactory();
      return null;
   }
}
{code}



  was:
AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans in a started user transaction (UT1).  Allow the beans invoked in the same transaction, to share the same persistence context.  

One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).

Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.

Some of the AS5 code is pasted below for easy reference.

{code}
public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
{
   private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);

   public String getName()
   {
      return this.getClass().getName();
   }

   public Object invoke(Invocation invocation) throws Throwable
   {
      log.debug("++++ LongLivedSessionPropagationInterceptor");
      StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
      StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();

      Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
      if (extendedPCs == null || extendedPCs.size() == 0)
      {
         return invocation.invokeNext();
      }

      TransactionManager tm = TxUtil.getTransactionManager();
      if (tm.getTransaction() != null)
      {
         for (String kernelname : extendedPCs.keySet())
         {
            EntityManager manager = extendedPCs.get(kernelname);
            ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
            factory.registerExtendedWithTransaction(manager);
         }
      }
      return invocation.invokeNext();
   }
}
{code}

{code}
public class EJB3XPCResolver implements XPCResolver
{
   private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
   /**
    * Query the current stateful bean contexts for the specified XPC.
    */
   public EntityManager getExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;

         em = beanContext.getExtendedPersistenceContext(kernelName);
         if (em != null) {
            log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
            return em;
         }
         /**
          * Look for XPC in current bean set.
          */
         log.info("looking for existing XPC with scoped pu name=" + kernelName);

         List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
         for( StatefulBeanContext bc : beanContexts)
         {
            em = bc.getExtendedPersistenceContext(kernelName);
            if (em != null) {
               log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
               //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
               beanContext.addExtendedPersistenceContext(kernelName, em);
               return em;
            }
            log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
         }
      }
      log.info("XPC not found scoped, search done, pu name=" + kernelName);
      return null;
   }

   @Override
   public EntityManager createExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;
         ManagedEntityManagerFactory factory=
            ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
         if (factory != null)
         {
            em = factory.createEntityManager();
            if (em != null)
            {
               beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
               log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
               /**
                * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
                *
                */

//               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
//               for( StatefulBeanContext bc : beanContexts)
//               {
//                  bc.addExtendedPersistenceContext(kernelName, em);
//               }
            }
         }

         return em;
      }
      return null;
   }
}
{code}

{code}
public class ManagedEntityManagerFactoryHelper
{
   public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
   {
      PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
      if(pu != null)
         return pu.getManagedFactory();
      return null;
   }
}
{code}




    
> add lazy xpc inheritance to handle legacy case, remote client with UserTransaction fails on 2nd SFSB invocation when using extended persistence context
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2504
>                 URL: https://issues.jboss.org/browse/WFLY-2504
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 9.0.0.CR1
>
>
> AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans (SFSB1+SFSB2) in a started user transaction (UT1).  Each of the stateful beans reference the same extended persistence context by name.  In AS5, both stateful beans will share the same extended persistence unit context but on AS7/WF8, each bean has its own extended persistence unit context.  Having both XPCS involved in the same user transaction, causes an (EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it...) error to be thrown.
> On AS7/WF8, Allow the beans invoked in the same transaction, to share the same persistence context.  
> One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).
> Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.
> Some of the AS5 code is pasted below for easy reference.
> {code}
> public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
> {
>    private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);
>    public String getName()
>    {
>       return this.getClass().getName();
>    }
>    public Object invoke(Invocation invocation) throws Throwable
>    {
>       log.debug("++++ LongLivedSessionPropagationInterceptor");
>       StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
>       StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();
>       Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
>       if (extendedPCs == null || extendedPCs.size() == 0)
>       {
>          return invocation.invokeNext();
>       }
>       TransactionManager tm = TxUtil.getTransactionManager();
>       if (tm.getTransaction() != null)
>       {
>          for (String kernelname : extendedPCs.keySet())
>          {
>             EntityManager manager = extendedPCs.get(kernelname);
>             ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
>             factory.registerExtendedWithTransaction(manager);
>          }
>       }
>       return invocation.invokeNext();
>    }
> }
> {code}
> {code}
> public class EJB3XPCResolver implements XPCResolver
> {
>    private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
>    /**
>     * Query the current stateful bean contexts for the specified XPC.
>     */
>    public EntityManager getExtendedPersistenceContext(String kernelName)
>    {
>       StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();
>       if (beanContext != null)
>       {
>          EntityManager em = null;
>          em = beanContext.getExtendedPersistenceContext(kernelName);
>          if (em != null) {
>             log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
>             return em;
>          }
>          /**
>           * Look for XPC in current bean set.
>           */
>          log.info("looking for existing XPC with scoped pu name=" + kernelName);
>          List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
>          for( StatefulBeanContext bc : beanContexts)
>          {
>             em = bc.getExtendedPersistenceContext(kernelName);
>             if (em != null) {
>                log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
>                //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
>                beanContext.addExtendedPersistenceContext(kernelName, em);
>                return em;
>             }
>             log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
>          }
>       }
>       log.info("XPC not found scoped, search done, pu name=" + kernelName);
>       return null;
>    }
>    @Override
>    public EntityManager createExtendedPersistenceContext(String kernelName)
>    {
>       StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();
>       if (beanContext != null)
>       {
>          EntityManager em = null;
>          ManagedEntityManagerFactory factory=
>             ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
>          if (factory != null)
>          {
>             em = factory.createEntityManager();
>             if (em != null)
>             {
>                beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
>                log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
>                /**
>                 * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
>                 *
>                 */
> //               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
> //               for( StatefulBeanContext bc : beanContexts)
> //               {
> //                  bc.addExtendedPersistenceContext(kernelName, em);
> //               }
>             }
>          }
>          return em;
>       }
>       return null;
>    }
> }
> {code}
> {code}
> public class ManagedEntityManagerFactoryHelper
> {
>    public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
>    {
>       PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
>       if(pu != null)
>          return pu.getManagedFactory();
>       return 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 issues at jboss.org  Tue Jan  7 15:18:32 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jan 2014 15:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2504) add lazy xpc inheritance to
 handle legacy case,
 remote client with UserTransaction fails on 2nd SFSB invocation when using
 extended persistence context
In-Reply-To: <JIRA.12524993.1384351632000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524993.1384351632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524993.1384351632000.33822.1389125912948@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2504:
-------------------------------

    Description: 
AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans (SFSB1+SFSB2) in a started user transaction (UT1).  Each of the stateful beans reference the same extended persistence context by name.  In AS5, both stateful beans will share the same extended persistence unit context but on AS7/WF8, each bean has its own extended persistence unit context.  Having both XPCS involved in the same user transaction, causes an (EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it...) error to be thrown.

On AS7/WF8, Allow the separate (remote) stateful beans to share the same persistence context.  

One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).

Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.

Some of the AS5 code is pasted below for easy reference.

{code}
public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
{
   private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);

   public String getName()
   {
      return this.getClass().getName();
   }

   public Object invoke(Invocation invocation) throws Throwable
   {
      log.debug("++++ LongLivedSessionPropagationInterceptor");
      StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
      StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();

      Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
      if (extendedPCs == null || extendedPCs.size() == 0)
      {
         return invocation.invokeNext();
      }

      TransactionManager tm = TxUtil.getTransactionManager();
      if (tm.getTransaction() != null)
      {
         for (String kernelname : extendedPCs.keySet())
         {
            EntityManager manager = extendedPCs.get(kernelname);
            ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
            factory.registerExtendedWithTransaction(manager);
         }
      }
      return invocation.invokeNext();
   }
}
{code}

{code}
public class EJB3XPCResolver implements XPCResolver
{
   private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
   /**
    * Query the current stateful bean contexts for the specified XPC.
    */
   public EntityManager getExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;

         em = beanContext.getExtendedPersistenceContext(kernelName);
         if (em != null) {
            log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
            return em;
         }
         /**
          * Look for XPC in current bean set.
          */
         log.info("looking for existing XPC with scoped pu name=" + kernelName);

         List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
         for( StatefulBeanContext bc : beanContexts)
         {
            em = bc.getExtendedPersistenceContext(kernelName);
            if (em != null) {
               log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
               //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
               beanContext.addExtendedPersistenceContext(kernelName, em);
               return em;
            }
            log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
         }
      }
      log.info("XPC not found scoped, search done, pu name=" + kernelName);
      return null;
   }

   @Override
   public EntityManager createExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;
         ManagedEntityManagerFactory factory=
            ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
         if (factory != null)
         {
            em = factory.createEntityManager();
            if (em != null)
            {
               beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
               log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
               /**
                * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
                *
                */

//               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
//               for( StatefulBeanContext bc : beanContexts)
//               {
//                  bc.addExtendedPersistenceContext(kernelName, em);
//               }
            }
         }

         return em;
      }
      return null;
   }
}
{code}

{code}
public class ManagedEntityManagerFactoryHelper
{
   public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
   {
      PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
      if(pu != null)
         return pu.getManagedFactory();
      return null;
   }
}
{code}



  was:
AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans (SFSB1+SFSB2) in a started user transaction (UT1).  Each of the stateful beans reference the same extended persistence context by name.  In AS5, both stateful beans will share the same extended persistence unit context but on AS7/WF8, each bean has its own extended persistence unit context.  Having both XPCS involved in the same user transaction, causes an (EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it...) error to be thrown.

On AS7/WF8, Allow the beans invoked in the same transaction, to share the same persistence context.  

One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).

Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.

Some of the AS5 code is pasted below for easy reference.

{code}
public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
{
   private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);

   public String getName()
   {
      return this.getClass().getName();
   }

   public Object invoke(Invocation invocation) throws Throwable
   {
      log.debug("++++ LongLivedSessionPropagationInterceptor");
      StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
      StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();

      Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
      if (extendedPCs == null || extendedPCs.size() == 0)
      {
         return invocation.invokeNext();
      }

      TransactionManager tm = TxUtil.getTransactionManager();
      if (tm.getTransaction() != null)
      {
         for (String kernelname : extendedPCs.keySet())
         {
            EntityManager manager = extendedPCs.get(kernelname);
            ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
            factory.registerExtendedWithTransaction(manager);
         }
      }
      return invocation.invokeNext();
   }
}
{code}

{code}
public class EJB3XPCResolver implements XPCResolver
{
   private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
   /**
    * Query the current stateful bean contexts for the specified XPC.
    */
   public EntityManager getExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;

         em = beanContext.getExtendedPersistenceContext(kernelName);
         if (em != null) {
            log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
            return em;
         }
         /**
          * Look for XPC in current bean set.
          */
         log.info("looking for existing XPC with scoped pu name=" + kernelName);

         List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
         for( StatefulBeanContext bc : beanContexts)
         {
            em = bc.getExtendedPersistenceContext(kernelName);
            if (em != null) {
               log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
               //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
               beanContext.addExtendedPersistenceContext(kernelName, em);
               return em;
            }
            log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
         }
      }
      log.info("XPC not found scoped, search done, pu name=" + kernelName);
      return null;
   }

   @Override
   public EntityManager createExtendedPersistenceContext(String kernelName)
   {
      StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();

      if (beanContext != null)
      {
         EntityManager em = null;
         ManagedEntityManagerFactory factory=
            ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
         if (factory != null)
         {
            em = factory.createEntityManager();
            if (em != null)
            {
               beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
               log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
               /**
                * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
                *
                */

//               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
//               for( StatefulBeanContext bc : beanContexts)
//               {
//                  bc.addExtendedPersistenceContext(kernelName, em);
//               }
            }
         }

         return em;
      }
      return null;
   }
}
{code}

{code}
public class ManagedEntityManagerFactoryHelper
{
   public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
   {
      PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
      if(pu != null)
         return pu.getManagedFactory();
      return null;
   }
}
{code}




    
> add lazy xpc inheritance to handle legacy case, remote client with UserTransaction fails on 2nd SFSB invocation when using extended persistence context
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2504
>                 URL: https://issues.jboss.org/browse/WFLY-2504
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 9.0.0.CR1
>
>
> AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans (SFSB1+SFSB2) in a started user transaction (UT1).  Each of the stateful beans reference the same extended persistence context by name.  In AS5, both stateful beans will share the same extended persistence unit context but on AS7/WF8, each bean has its own extended persistence unit context.  Having both XPCS involved in the same user transaction, causes an (EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it...) error to be thrown.
> On AS7/WF8, Allow the separate (remote) stateful beans to share the same persistence context.  
> One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).
> Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.
> Some of the AS5 code is pasted below for easy reference.
> {code}
> public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
> {
>    private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);
>    public String getName()
>    {
>       return this.getClass().getName();
>    }
>    public Object invoke(Invocation invocation) throws Throwable
>    {
>       log.debug("++++ LongLivedSessionPropagationInterceptor");
>       StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
>       StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();
>       Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
>       if (extendedPCs == null || extendedPCs.size() == 0)
>       {
>          return invocation.invokeNext();
>       }
>       TransactionManager tm = TxUtil.getTransactionManager();
>       if (tm.getTransaction() != null)
>       {
>          for (String kernelname : extendedPCs.keySet())
>          {
>             EntityManager manager = extendedPCs.get(kernelname);
>             ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
>             factory.registerExtendedWithTransaction(manager);
>          }
>       }
>       return invocation.invokeNext();
>    }
> }
> {code}
> {code}
> public class EJB3XPCResolver implements XPCResolver
> {
>    private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
>    /**
>     * Query the current stateful bean contexts for the specified XPC.
>     */
>    public EntityManager getExtendedPersistenceContext(String kernelName)
>    {
>       StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();
>       if (beanContext != null)
>       {
>          EntityManager em = null;
>          em = beanContext.getExtendedPersistenceContext(kernelName);
>          if (em != null) {
>             log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
>             return em;
>          }
>          /**
>           * Look for XPC in current bean set.
>           */
>          log.info("looking for existing XPC with scoped pu name=" + kernelName);
>          List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
>          for( StatefulBeanContext bc : beanContexts)
>          {
>             em = bc.getExtendedPersistenceContext(kernelName);
>             if (em != null) {
>                log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
>                //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
>                beanContext.addExtendedPersistenceContext(kernelName, em);
>                return em;
>             }
>             log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
>          }
>       }
>       log.info("XPC not found scoped, search done, pu name=" + kernelName);
>       return null;
>    }
>    @Override
>    public EntityManager createExtendedPersistenceContext(String kernelName)
>    {
>       StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();
>       if (beanContext != null)
>       {
>          EntityManager em = null;
>          ManagedEntityManagerFactory factory=
>             ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
>          if (factory != null)
>          {
>             em = factory.createEntityManager();
>             if (em != null)
>             {
>                beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
>                log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
>                /**
>                 * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
>                 *
>                 */
> //               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
> //               for( StatefulBeanContext bc : beanContexts)
> //               {
> //                  bc.addExtendedPersistenceContext(kernelName, em);
> //               }
>             }
>          }
>          return em;
>       }
>       return null;
>    }
> }
> {code}
> {code}
> public class ManagedEntityManagerFactoryHelper
> {
>    public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
>    {
>       PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
>       if(pu != null)
>          return pu.getManagedFactory();
>       return 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 issues at jboss.org  Tue Jan  7 15:22:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Jan 2014 15:22:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2719) NullPointerException on first
 request after deployment using beans.xml
In-Reply-To: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528793.1389121287000.33828.1389126152981@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2719:
--------------------------------------

This is already fixed in Undertow upstream, should be upstream soon. You can just disable session persistence as a workaround. 
                
> NullPointerException on first request after deployment using beans.xml
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2719
>                 URL: https://issues.jboss.org/browse/WFLY-2719
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: James Bodkin
>            Assignee: Stuart Douglas
>            Priority: Minor
>         Attachments: dew.zip
>
>
> A NullPointerException occurs on the first request to the WildFly AS if the war package already exists and has been deployed via maven on both occasions causing an 500 Internal Server Error on the client.
> Removing the beans.xml from WEB-INF stops the error from occurring but services aren't injected.
> 02:36:11,177 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
> 	at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
> 	at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
> 	at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
> 	at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
> 	at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
> 	at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
> 	at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
> 	at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
> 	at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
> 	at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:46)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.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 issues at jboss.org  Tue Jan  7 15:28:32 2014
From: issues at jboss.org (Matus Zamborsky (JIRA))
Date: Tue, 7 Jan 2014 15:28:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.33853.1389126512920@jira02.app.mwc.hst.phx2.redhat.com>


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

Matus Zamborsky commented on WFLY-2690:
---------------------------------------

In that case, I don't see a way how to make the ID deterministic, because the class is loaded by class loader dynamically created during JSP loading. Only deterministic and distinct information is the jsp name, but I have no idea how it will be possible to pass this information down to weld and still don't make weld dependent on this specific class loader.

Does anybody know, how this problem was solved in AS 7 ?
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Tue Jan  7 15:34:32 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Tue, 7 Jan 2014 15:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Per-deployment descriptor
	replacement
In-Reply-To: <JIRA.12528797.1389126869435@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869435@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869435.33876.1389126872670@jira02.app.mwc.hst.phx2.redhat.com>

Joshua Henn created WFLY-2720:
---------------------------------

             Summary: Per-deployment descriptor replacement
                 Key: WFLY-2720
                 URL: https://issues.jboss.org/browse/WFLY-2720
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Joshua Henn


Currently descriptor replacement (ie. in persistence.xml) is possible via system properties.  Unfortunately since system properties are global it is not possible to have per-deployment descriptor replacement.

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements.

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

From issues at jboss.org  Tue Jan  7 15:44:33 2014
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Tue, 7 Jan 2014 15:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2504) add lazy xpc inheritance to
 handle legacy case,
 remote client with UserTransaction fails on 2nd SFSB invocation when using
 extended persistence context
In-Reply-To: <JIRA.12524993.1384351632000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524993.1384351632000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524993.1384351632000.33881.1389127473091@jira02.app.mwc.hst.phx2.redhat.com>


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

Sande Gilda commented on WFLY-2504:
-----------------------------------

Created a documentation bug for the Migration Guide for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1049610
                
> add lazy xpc inheritance to handle legacy case, remote client with UserTransaction fails on 2nd SFSB invocation when using extended persistence context
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2504
>                 URL: https://issues.jboss.org/browse/WFLY-2504
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 9.0.0.CR1
>
>
> AS5 allowed a remote client to instantiate a set of stateful session beans (e.g. SFSB1 + SFSB2) and then call the remote stateful session beans (SFSB1+SFSB2) in a started user transaction (UT1).  Each of the stateful beans reference the same extended persistence context by name.  In AS5, both stateful beans will share the same extended persistence unit context but on AS7/WF8, each bean has its own extended persistence unit context.  Having both XPCS involved in the same user transaction, causes an (EJBException: JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it...) error to be thrown.
> On AS7/WF8, Allow the separate (remote) stateful beans to share the same persistence context.  
> One approach might be to defer creation of the extended persistence context until the first invocation (need to verify that this is the right approach).
> Currently, we support shallow + deep extended persistence context inheritance.  This will be a "lazy" variation of the deep XPC inheritance.
> Some of the AS5 code is pasted below for easy reference.
> {code}
> public class ExtendedPersistenceContextPropagationInterceptor implements Interceptor
> {
>    private static final Logger log = Logger.getLogger(ExtendedPersistenceContextPropagationInterceptor.class);
>    public String getName()
>    {
>       return this.getClass().getName();
>    }
>    public Object invoke(Invocation invocation) throws Throwable
>    {
>       log.debug("++++ LongLivedSessionPropagationInterceptor");
>       StatefulContainerInvocation ejb = (StatefulContainerInvocation) invocation;
>       StatefulBeanContext ctx = (StatefulBeanContext) ejb.getBeanContext();
>       Map<String, EntityManager> extendedPCs = ctx.getExtendedPersistenceContexts();
>       if (extendedPCs == null || extendedPCs.size() == 0)
>       {
>          return invocation.invokeNext();
>       }
>       TransactionManager tm = TxUtil.getTransactionManager();
>       if (tm.getTransaction() != null)
>       {
>          for (String kernelname : extendedPCs.keySet())
>          {
>             EntityManager manager = extendedPCs.get(kernelname);
>             ManagedEntityManagerFactory factory = ManagedEntityManagerFactoryHelper.getManagedEntityManagerFactory(kernelname);
>             factory.registerExtendedWithTransaction(manager);
>          }
>       }
>       return invocation.invokeNext();
>    }
> }
> {code}
> {code}
> public class EJB3XPCResolver implements XPCResolver
> {
>    private static final Logger log = Logger.getLogger(EJB3XPCResolver.class);
>    /**
>     * Query the current stateful bean contexts for the specified XPC.
>     */
>    public EntityManager getExtendedPersistenceContext(String kernelName)
>    {
>       StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();
>       if (beanContext != null)
>       {
>          EntityManager em = null;
>          em = beanContext.getExtendedPersistenceContext(kernelName);
>          if (em != null) {
>             log.info("current SFSB has XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
>             return em;
>          }
>          /**
>           * Look for XPC in current bean set.
>           */
>          log.info("looking for existing XPC with scoped pu name=" + kernelName);
>          List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
>          for( StatefulBeanContext bc : beanContexts)
>          {
>             em = bc.getExtendedPersistenceContext(kernelName);
>             if (em != null) {
>                log.info("found existing XPC with scoped pu name=" + kernelName + " on SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
>                //  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
>                beanContext.addExtendedPersistenceContext(kernelName, em);
>                return em;
>             }
>             log.info("XPC not found yet, scoped pu name=" + kernelName + " not in SFSB bean=" + bc.getContainer().getIdentifier() + bc.getId());
>          }
>       }
>       log.info("XPC not found scoped, search done, pu name=" + kernelName);
>       return null;
>    }
>    @Override
>    public EntityManager createExtendedPersistenceContext(String kernelName)
>    {
>       StatefulBeanContext beanContext = StatefulBeanContext.currentBean.get();
>       if (beanContext != null)
>       {
>          EntityManager em = null;
>          ManagedEntityManagerFactory factory=
>             ((PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName)).getManagedFactory();
>          if (factory != null)
>          {
>             em = factory.createEntityManager();
>             if (em != null)
>             {
>                beanContext.addExtendedPersistenceContext(factory.getKernelName(), em);
>                log.info("created new XPC with scoped pu name=" + kernelName + " on SFSB bean=" + beanContext.getContainer().getIdentifier() + beanContext.getId());
>                /**
>                 * TODO:  Propagate created XPC as required (7.6.2.1 Inheritance of Extended Persistence Context
>                 *
>                 */
> //               List <StatefulBeanContext> beanContexts = StatefulBeanContext.currentBean.getList();
> //               for( StatefulBeanContext bc : beanContexts)
> //               {
> //                  bc.addExtendedPersistenceContext(kernelName, em);
> //               }
>             }
>          }
>          return em;
>       }
>       return null;
>    }
> }
> {code}
> {code}
> public class ManagedEntityManagerFactoryHelper
> {
>    public static ManagedEntityManagerFactory getManagedEntityManagerFactory(String kernelName)
>    {
>       PersistenceUnitDeployment pu = (PersistenceUnitDeployment) PersistenceUnitRegistry.getPersistenceUnit(kernelName);
>       if(pu != null)
>          return pu.getManagedFactory();
>       return 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 issues at jboss.org  Tue Jan  7 16:08:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 16:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.33900.1389128913369@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1014911|https://bugzilla.redhat.com/show_bug.cgi?id=1014911] from POST to MODIFIED
                
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>         Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

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

From issues at jboss.org  Tue Jan  7 16:12:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 16:12:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2514) Using directory grouping
 by-type results in the wrong logging.properties file being used
In-Reply-To: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525194.1384479524000.33905.1389129153131@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1031129|https://bugzilla.redhat.com/show_bug.cgi?id=1031129] from POST to MODIFIED
                
> Using directory grouping by-type results in the wrong logging.properties file being used
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2514
>                 URL: https://issues.jboss.org/browse/WFLY-2514
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> When defining servers with {{directory-grouping="by-type"}} the wrong directory is used in the {{ManagedServerBootCmdFactory}}. This causes the {{domain/configuration/logging.properties}} to always be used which is the incorrect configuration to use.

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

From issues at jboss.org  Tue Jan  7 16:12:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 16:12:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager
 module needs a dependency on javax.mail.api
In-Reply-To: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490786.1367277432000.33907.1389129153224@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 971076|https://bugzilla.redhat.com/show_bug.cgi?id=971076] from ASSIGNED to MODIFIED
                
> org.jboss.log4j.logmanager module needs a dependency on javax.mail.api
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1300
>                 URL: https://issues.jboss.org/browse/WFLY-1300
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too.

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

From issues at jboss.org  Tue Jan  7 16:14:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 7 Jan 2014 16:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError:
 expected:<200> but was:<500>' in
 org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
In-Reply-To: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527235.1386342825000.33911.1389129273560@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1034229|https://bugzilla.redhat.com/show_bug.cgi?id=1034229] from ASSIGNED to MODIFIED
                
> Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2618
>                 URL: https://issues.jboss.org/browse/WFLY-2618
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-3843551226685549253&tab=testDetails
> The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s.

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

From issues at jboss.org  Tue Jan  7 18:34:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 7 Jan 2014 18:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-781) Release PicketBox
	4.0.20.Beta4
In-Reply-To: <JIRA.12528805.1389137623182@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528805.1389137623182@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528805.1389137623182.33977.1389137672770@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created SECURITY-781:
---------------------------------------

             Summary: Release PicketBox 4.0.20.Beta4
                 Key: SECURITY-781
                 URL: https://issues.jboss.org/browse/SECURITY-781
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen




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

From issues at jboss.org  Tue Jan  7 20:26:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 7 Jan 2014 20:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2721) Make the add-user password
 "requirements" prompt match the password.restriction setting
In-Reply-To: <JIRA.12528807.1389144297654@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528807.1389144297654@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528807.1389144297654.34017.1389144393430@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2721:
--------------------------------------

             Summary: Make the add-user password "requirements" prompt match the password.restriction setting
                 Key: WFLY-2721
                 URL: https://issues.jboss.org/browse/WFLY-2721
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
    Affects Versions: 8.0.0.CR1
            Reporter: Brian Stansberry


When you use add-user.sh it gives you a message re password "requirements"

Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
...

But then, if add-user.properties has password.restriction=WARN (the default) the requirements are not enforced:

Password :
JBAS015269: Password must have at least 8 characters!
Are you sure you want to use the password entered yes/no? yes 

This is a bit confusing. Better would be to tailor the initial prompt to the password.restriction setting. For example for WARN (and perhaps RELAX):

Password recommendations are listed below. To modify these recommendations edit the add-user.properties configuration 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 issues at jboss.org  Tue Jan  7 22:06:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 7 Jan 2014 22:06:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2715) Upgrade to PicketBox
	4.0.20.Beta4
In-Reply-To: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528696.1389055292000.34075.1389150392764@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefan Guilhen updated WFLY-2715:
---------------------------------

    Summary: Upgrade to PicketBox 4.0.20.Beta4  (was: Upgrade to PicketBox 4.0.20.Beta3)

    
> Upgrade to PicketBox 4.0.20.Beta4
> ---------------------------------
>
>                 Key: WFLY-2715
>                 URL: https://issues.jboss.org/browse/WFLY-2715
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.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 issues at jboss.org  Tue Jan  7 22:06:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 7 Jan 2014 22:06:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2715) Upgrade to PicketBox
	4.0.20.Beta4
In-Reply-To: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528696.1389055292000.34076.1389150392794@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefan Guilhen updated WFLY-2715:
---------------------------------

    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/5674)

    
> Upgrade to PicketBox 4.0.20.Beta4
> ---------------------------------
>
>                 Key: WFLY-2715
>                 URL: https://issues.jboss.org/browse/WFLY-2715
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.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 issues at jboss.org  Wed Jan  8 01:16:34 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 8 Jan 2014 01:16:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.34143.1389161794732@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2690:
---------------------------------------

We can sacrifice deterministic IDs for InjectionTargets of JSP components, since these will never be passivated. However, we cannot do this globally in Weld's AnnotatedTypeIdentifier since that would affect all component types including contextual ones. See the PR.

AFAIK in AS7 this approach of using multiple classloaders to load a single class was not used and therefore the problem did not occur.
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Wed Jan  8 01:24:32 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 8 Jan 2014 01:24:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.34146.1389162272763@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger updated WFLY-2690:
----------------------------------

    Fix Version/s: 8.0.0.Final

    
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

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


From issues at jboss.org  Wed Jan  8 01:37:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 8 Jan 2014 01:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2722) @EJB injection in interceptor
 class and in target class result in injection of instances of two different
 classes
In-Reply-To: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528310.1387545321000.34171.1389163053277@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger moved WELD-1576 to WFLY-2722:
---------------------------------------------

              Project: WildFly  (was: Weld)
                  Key: WFLY-2722  (was: WELD-1576)
    Affects Version/s: 8.0.0.CR1
                           (was: 2.1.1.Final)
          Component/s: CDI / Weld
                           (was: Interceptors and Decorators)
                           (was: WildFly integration)
             Security: Public

    
> @EJB injection in interceptor class and in target class result in injection of instances of two different classes
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2722
>                 URL: https://issues.jboss.org/browse/WFLY-2722
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Matus Abaffy
>            Assignee: Jozef Hartinger
>
> Interceptors spec, 2.2.1 - Interceptor Environment:
> bq. Interceptor class shares the enterprise naming context of its associated target class. (1)
> Assume the following scenario:
> Ear: test-ejb.jar, test1.war, test2.war
>   test-ejb.jar: Animal, BarBinding
>   test1.war: BarInterceptor, Dog
>   test2.war: Bar, Cat
> Short description of the classes:
> {code}
> @Stateful public class Dog implements Animal {...}
> {code}
> {code}
> @Stateful public class Cat implements Animal {...}
> {code}
> {code}
> @BarBinding @Stateless
> public class Bar {
>     @EJB
>     Animal animal;
> }
> {code}
> {code}
> @BarBinding @Priority(1000) @Interceptor
> public class BarInterceptor {
>     @EJB
>     Animal animal;
> }
> {code}
> Bar gets injected an instance of Cat, whereas BarInterceptor gets injected an instance of Dog, which IMHO contradicts (1).
> Test case at: https://github.com/cdi-spec/cdi-tck/pull/38
> (InterceptorEnvironmentJNDITest, InterceptorEnvironmentJNDISessionBeanTest)

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

From issues at jboss.org  Wed Jan  8 02:47:32 2014
From: issues at jboss.org (Robert Panzer (JIRA))
Date: Wed, 8 Jan 2014 02:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-370) Deployment of a war with 2
 web-fragments both containing ejb-local-refs fails
In-Reply-To: <JIRA.12528756.1389114759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528756.1389114759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528756.1389114759000.34182.1389167252773@jira02.app.mwc.hst.phx2.redhat.com>


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

Robert Panzer commented on JBMETA-370:
--------------------------------------

The affected version is metadata 8.0.0.Beta5.
Unfortunately I cannot select that in the form.
                
> Deployment of a war with 2 web-fragments both containing ejb-local-refs fails
> -----------------------------------------------------------------------------
>
>                 Key: JBMETA-370
>                 URL: https://issues.jboss.org/browse/JBMETA-370
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>         Environment: Win7, Oracle JDK 1.7.0_45, Wildfly 8.0.0-CR1
>            Reporter: Robert Panzer
>
> When trying to deploy a WAR containing two web-fragments both containing ejb-local-refs the deployment fails with this error message:
> 17:54:24,669 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "testear.ear" (runtime-name: "testear.ear")
> 17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "testwar.war")
> 17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "ejbjar.jar")
> 17:55:55,538 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartExcep
> tion in service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
>         at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:294)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         ... 5 more
> Caused by: java.lang.IllegalArgumentException: Null administeredObjects
>         at org.jboss.metadata.javaee.spec.RemoteEnvironmentRefsGroupMetaData.setAdministeredObjects(RemoteEnvironmentRefsGroupMetaData.java:431)
>         at org.jboss.metadata.merge.javaee.spec.RemoteEnvironmentRefsGroupMetaDataMerger.augment(RemoteEnvironmentRefsGroupMetaDataMerger.java:337)
>         at org.jboss.metadata.merge.javaee.spec.EnvironmentRefsGroupMetaDataMerger.augment(EnvironmentRefsGroupMetaDataMerger.java:71)
>         at org.jboss.metadata.merge.web.spec.WebCommonMetaDataMerger.augment(WebCommonMetaDataMerger.java:383)
>         at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:292)
>         ... 6 more
> 17:55:55,621 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "testear.ear")]) - failure descr
> iption: {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"testear.ear\".\"testwar.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"testear.ear\"
> .\"testwar.war\".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment \"testwar.war\" of deployment \"testear.ear\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
>     Caused by: java.lang.IllegalArgumentException: Null administeredObjects"}}
> 17:55:55,881 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "testear.ear" (runtime-name : "testear.ear")
> 17:55:55,882 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."testear
> .ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
> There seems to be an error in the class RemoteEnvironmentRefsGroupMetaDataMerger because it calls dest.setAdministeredObjects() during augmentation even if the fragment does not contain administered objects (but entries in the ENC so that the merger is called.)
> I created a test application that shows the problem. You can find it at https://github.com/robertpanzer/webfragmenttest.git
> I can also provide a PR.

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

From issues at jboss.org  Wed Jan  8 03:01:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Jan 2014 03:01:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster
	acceptance test
In-Reply-To: <JIRA.12528813.1389168082285@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528813.1389168082285@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528813.1389168082285.34201.1389168093435@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1766:
------------------------------

             Summary: NAKACK2/UNICAST3: faster acceptance test
                 Key: JGRP-1766
                 URL: https://issues.jboss.org/browse/JGRP-1766
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message.
A faster acceptance test would be to check if the destination of the message batch matches, e.g.
* UNICAST3: {{MessageBatch.getDest() != null}}
* NAKACK2: {{MessageBatch.getDest() == nul}}

If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch.

Same for single messages: this is already done in UNICAST3, but not in NAKACK2.

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

From issues at jboss.org  Wed Jan  8 03:09:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Jan 2014 03:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster
	acceptance test
In-Reply-To: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528813.1389168082000.34207.1389168572778@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1766:
--------------------------------

CORRECTION: *we cannot do this for single messages in NAKACK2 !* The reason is that we might receive unicast messages, e.g. XMIT_REQ/XMIT_RSP messages, which need to get handled by NAKACK2...

This does work in UNICAST3, because it's the opposite of NAKACK2: it will never handle multicast messages (dest == null).
                
> NAKACK2/UNICAST3: faster acceptance test
> ----------------------------------------
>
>                 Key: JGRP-1766
>                 URL: https://issues.jboss.org/browse/JGRP-1766
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message.
> A faster acceptance test would be to check if the destination of the message batch matches, e.g.
> * UNICAST3: {{MessageBatch.getDest() != null}}
> * NAKACK2: {{MessageBatch.getDest() == nul}}
> If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch.
> Same for single messages: this is already done in UNICAST3, but not in NAKACK2.

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

From issues at jboss.org  Wed Jan  8 03:13:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Jan 2014 03:13:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster
	acceptance test
In-Reply-To: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528813.1389168082000.34210.1389168812785@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1766:
--------------------------------

Same for message batches: we might receive a message batch whose dest is non-null in NAKACK2, but still have to process it by iterating over its messages, because some messages might be XMIT_RSP/XMIT_REQ messages !

However, we can *ignore message batches whose destination is null in UNICAST3*. This is actually the only thing that can be changed in this JIRA !! :-)
                
> NAKACK2/UNICAST3: faster acceptance test
> ----------------------------------------
>
>                 Key: JGRP-1766
>                 URL: https://issues.jboss.org/browse/JGRP-1766
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message.
> A faster acceptance test would be to check if the destination of the message batch matches, e.g.
> * UNICAST3: {{MessageBatch.getDest() != null}}
> * NAKACK2: {{MessageBatch.getDest() == nul}}
> If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch.
> Same for single messages: this is already done in UNICAST3, but not in NAKACK2.

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

From issues at jboss.org  Wed Jan  8 04:09:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 04:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError:
 expected:<200> but was:<500>' in
 org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
In-Reply-To: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527235.1386342825000.34255.1389172172817@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2618:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1034229, https://bugzilla.redhat.com/show_bug.cgi?id=1049796  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1034229)

    
> Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2618
>                 URL: https://issues.jboss.org/browse/WFLY-2618
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-3843551226685549253&tab=testDetails
> The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s.

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

From issues at jboss.org  Wed Jan  8 04:23:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 04:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.34287.1389173013082@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1047536|https://bugzilla.redhat.com/show_bug.cgi?id=1047536] from MODIFIED to POST
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Wed Jan  8 04:53:34 2014
From: issues at jboss.org (Philipp Plogmann (JIRA))
Date: Wed, 8 Jan 2014 04:53:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2708) Solr fails to deploy on CR1
In-Reply-To: <JIRA.12528620.1388841454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528620.1388841454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528620.1388841454000.34396.1389174814351@jira02.app.mwc.hst.phx2.redhat.com>


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

Philipp Plogmann commented on WFLY-2708:
----------------------------------------

Hi,
I just encountered the same problem. This is caused by the implicit CDI scanning. See the Wildfly docs here: https://docs.jboss.org/author/display/WFLY8/CDI+Reference You can disable this for the whole application server by modifiying the subsystem entry in standalone.xml to  <subsystem xmlns="urn:jboss:domain:weld:2.0" require-bean-descriptor="true"/> or you can modify the war and add the descriptor to it which avoids the implicit scanning.
                
> Solr fails to deploy on CR1
> ---------------------------
>
>                 Key: WFLY-2708
>                 URL: https://issues.jboss.org/browse/WFLY-2708
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Rich Midwinter
>
> Solr (4.6) fails to deploy on CR1. I've had it working previously on Alpha builds and I gather it worked previously on Beta builds for someone else experiencing this issue - https://issues.apache.org/jira/browse/SOLR-5578
> 2014-01-04 12:59:34,138 WARN  [org.jboss.modules] (weld-worker-1) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module "deployment.solr.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/apache/hadoop/hdfs/web/re
> sources/UserProvider (Module "deployment.solr.war:main" from Service Module Loader)
>         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:428) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
>         at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:106) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
>         at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:94) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
>         at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
>         at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: com/sun/jersey/spi/inject/InjectableProvider
>         at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_25]
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:792) [rt.jar:1.7.0_25]
>         at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final]
>         ... 20 more
> Caused by: java.lang.ClassNotFoundException: com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
>         ... 24 more
> 2014-01-04 12:59:34,148 INFO  [org.jboss.weld.Bootstrap] (weld-worker-1) WELD-000119: Not generating any bean definitions from org.apache.hadoop.hdfs.web.resources.UserProvider because of underlying class loading error: Type com.sun.jersey.spi.inject.InjectableProvider from [Module "deployment.solr.war:main" from Service Module Loader] not found.  If this is unexpected, enable DEBUG logging to see the full error.
> 2014-01-04 12:59:34,893 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."solr.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."solr.war".WeldStartService: Failed to start service
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default
>   at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)
>   at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)
>         at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:361)
>         at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
>         at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
>         at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
>         at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
>         at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>         at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
>         at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
>         ... 3 more
> 2014-01-04 12:59:34,901 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "solr.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"solr.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"solr.war\".WeldStartService: Failed to start 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 issues at jboss.org  Wed Jan  8 05:01:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Jan 2014 05:01:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster
	acceptance test
In-Reply-To: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528813.1389168082000.34477.1389175294656@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1766:
--------------------------------

I need to retract the previous comment: message batches received by NAKACK2 have the same dest: so either all messages in a batch have dest=null or all messages have dest!= null ! So the first comment is still valid and this optimization can be also be done for NAKACK2 !
                
> NAKACK2/UNICAST3: faster acceptance test
> ----------------------------------------
>
>                 Key: JGRP-1766
>                 URL: https://issues.jboss.org/browse/JGRP-1766
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message.
> A faster acceptance test would be to check if the destination of the message batch matches, e.g.
> * UNICAST3: {{MessageBatch.getDest() != null}}
> * NAKACK2: {{MessageBatch.getDest() == nul}}
> If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch.
> Same for single messages: this is already done in UNICAST3, but not in NAKACK2.

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

From issues at jboss.org  Wed Jan  8 05:03:32 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 8 Jan 2014 05:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2721) Make the add-user password
 "requirements" prompt match the password.restriction setting
In-Reply-To: <JIRA.12528807.1389144297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528807.1389144297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528807.1389144297000.34506.1389175412997@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-2721:
--------------------------------------

    Assignee: Darran Lofthouse

    
> Make the add-user password "requirements" prompt match the password.restriction setting
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2721
>                 URL: https://issues.jboss.org/browse/WFLY-2721
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>
> When you use add-user.sh it gives you a message re password "requirements"
> Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
> ...
> But then, if add-user.properties has password.restriction=WARN (the default) the requirements are not enforced:
> Password :
> JBAS015269: Password must have at least 8 characters!
> Are you sure you want to use the password entered yes/no? yes 
> This is a bit confusing. Better would be to tailor the initial prompt to the password.restriction setting. For example for WARN (and perhaps RELAX):
> Password recommendations are listed below. To modify these recommendations edit the add-user.properties configuration 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 issues at jboss.org  Wed Jan  8 05:03:33 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 8 Jan 2014 05:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2721) Make the add-user password
 "requirements" prompt match the password.restriction setting
In-Reply-To: <JIRA.12528807.1389144297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528807.1389144297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528807.1389144297000.34509.1389175413166@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-2721:
-----------------------------------

    Fix Version/s: 8.0.0.Final

    
> Make the add-user password "requirements" prompt match the password.restriction setting
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2721
>                 URL: https://issues.jboss.org/browse/WFLY-2721
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> When you use add-user.sh it gives you a message re password "requirements"
> Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
> ...
> But then, if add-user.properties has password.restriction=WARN (the default) the requirements are not enforced:
> Password :
> JBAS015269: Password must have at least 8 characters!
> Are you sure you want to use the password entered yes/no? yes 
> This is a bit confusing. Better would be to tailor the initial prompt to the password.restriction setting. For example for WARN (and perhaps RELAX):
> Password recommendations are listed below. To modify these recommendations edit the add-user.properties configuration 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 issues at jboss.org  Wed Jan  8 05:07:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 05:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.34528.1389175652955@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2696:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1047519, https://bugzilla.redhat.com/show_bug.cgi?id=1047536, https://bugzilla.redhat.com/show_bug.cgi?id=1049824  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1047519, https://bugzilla.redhat.com/show_bug.cgi?id=1047536)

    
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Wed Jan  8 05:25:33 2014
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Wed, 8 Jan 2014 05:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2723) Accessing "serverInventory"
 without holding lock "serverInventoryLock"
In-Reply-To: <JIRA.12528821.1389176731818@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528821.1389176731818@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528821.1389176731818.34603.1389176733294@jira02.app.mwc.hst.phx2.redhat.com>

Rostislav Svoboda created WFLY-2723:
---------------------------------------

             Summary: Accessing "serverInventory" without holding lock "serverInventoryLock"
                 Key: WFLY-2723
                 URL: https://issues.jboss.org/browse/WFLY-2723
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Rostislav Svoboda
            Assignee: Emanuel Muckenhuber


Accessing "serverInventory" without holding lock "org.jboss.as.host.controller.DomainModelControllerService.serverInventoryLock". 
Elsewhere, "serverInventory" is accessed with "DomainModelControllerService.serverInventoryLock" held 4 out of 5 times.

https://github.com/wildfly/wildfly/blob/master/host-controller/src/main/java/org/jboss/as/host/controller/DomainModelControllerService.java#L364

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

From issues at jboss.org  Wed Jan  8 05:35:32 2014
From: issues at jboss.org (Philipp Plogmann (JIRA))
Date: Wed, 8 Jan 2014 05:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2724) JAX-RS method validation
 fails with generic interface
In-Reply-To: <JIRA.12528822.1389177240396@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528822.1389177240396@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528822.1389177240396.34606.1389177332901@jira02.app.mwc.hst.phx2.redhat.com>

Philipp Plogmann created WFLY-2724:
--------------------------------------

             Summary: JAX-RS method validation fails with generic interface
                 Key: WFLY-2724
                 URL: https://issues.jboss.org/browse/WFLY-2724
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: REST
    Affects Versions: 8.0.0.CR1
            Reporter: Philipp Plogmann
            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 issues at jboss.org  Wed Jan  8 05:39:32 2014
From: issues at jboss.org (Philipp Plogmann (JIRA))
Date: Wed, 8 Jan 2014 05:39:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2724) IllegalArgumentException in
 JAX-RS caused by MethodValidation
In-Reply-To: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528822.1389177240000.34609.1389177572785@jira02.app.mwc.hst.phx2.redhat.com>


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

Philipp Plogmann updated WFLY-2724:
-----------------------------------

        Summary: IllegalArgumentException in JAX-RS caused by MethodValidation  (was: JAX-RS method validation fails with generic interface)
    Description: 
If a JaxRS service implements an interface the calls to this method fail with an IllegalArgumentException:

java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)

The same resource class without the interface works without a problem.

Example code:
{quote}

public interface RestResource<T, K> {

	T get(K id);

}

@Path("test")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class TestRestResource implements RestResource<Test, Long> {

	public TestRestResource() {
	}

	@GET
	@Path("{id}")
	@Override
	public Test get(@PathParam("id") Long id) {
		return new Test();
	}

}
{quote}
        Affects: Compatibility/Configuration

    
> IllegalArgumentException in JAX-RS caused by MethodValidation
> -------------------------------------------------------------
>
>                 Key: WFLY-2724
>                 URL: https://issues.jboss.org/browse/WFLY-2724
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Philipp Plogmann
>            Assignee: Stuart Douglas
>
> If a JaxRS service implements an interface the calls to this method fail with an IllegalArgumentException:
> java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)
> The same resource class without the interface works without a problem.
> Example code:
> {quote}
> public interface RestResource<T, K> {
> 	T get(K id);
> }
> @Path("test")
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public class TestRestResource implements RestResource<Test, Long> {
> 	public TestRestResource() {
> 	}
> 	@GET
> 	@Path("{id}")
> 	@Override
> 	public Test get(@PathParam("id") Long id) {
> 		return new Test();
> 	}
> }
> {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 issues at jboss.org  Wed Jan  8 05:41:32 2014
From: issues at jboss.org (Philipp Plogmann (JIRA))
Date: Wed, 8 Jan 2014 05:41:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2724) IllegalArgumentException in
 JAX-RS caused by MethodValidation
In-Reply-To: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528822.1389177240000.34614.1389177692886@jira02.app.mwc.hst.phx2.redhat.com>


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

Philipp Plogmann updated WFLY-2724:
-----------------------------------

    Attachment: WildflyRestTest.war


A sample project replicating this behaviour.

The first URL calls the resource which implements the interface. This call fails.

http://localhost:8080/WildflyRestTest/test/1

The second one contains the same resource without the interface declaration. This call succeeds:

http://localhost:8080/WildflyRestTest/test2/1
                
> IllegalArgumentException in JAX-RS caused by MethodValidation
> -------------------------------------------------------------
>
>                 Key: WFLY-2724
>                 URL: https://issues.jboss.org/browse/WFLY-2724
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Philipp Plogmann
>            Assignee: Stuart Douglas
>         Attachments: WildflyRestTest.war
>
>
> If a JaxRS service implements an interface the calls to this method fail with an IllegalArgumentException:
> java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)
> The same resource class without the interface works without a problem.
> Example code:
> {quote}
> public interface RestResource<T, K> {
> 	T get(K id);
> }
> @Path("test")
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public class TestRestResource implements RestResource<Test, Long> {
> 	public TestRestResource() {
> 	}
> 	@GET
> 	@Path("{id}")
> 	@Override
> 	public Test get(@PathParam("id") Long id) {
> 		return new Test();
> 	}
> }
> {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 issues at jboss.org  Wed Jan  8 05:45:33 2014
From: issues at jboss.org (Philipp Plogmann (JIRA))
Date: Wed, 8 Jan 2014 05:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2724) IllegalArgumentException in
 JAX-RS caused by MethodValidation
In-Reply-To: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528822.1389177240000.34621.1389177933355@jira02.app.mwc.hst.phx2.redhat.com>


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

Philipp Plogmann updated WFLY-2724:
-----------------------------------

    Attachment: WildflyRestTest.zip


Maven project for the sample application.
                
> IllegalArgumentException in JAX-RS caused by MethodValidation
> -------------------------------------------------------------
>
>                 Key: WFLY-2724
>                 URL: https://issues.jboss.org/browse/WFLY-2724
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Philipp Plogmann
>            Assignee: Stuart Douglas
>         Attachments: WildflyRestTest.war, WildflyRestTest.zip
>
>
> If a JaxRS service implements an interface the calls to this method fail with an IllegalArgumentException:
> java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)
> The same resource class without the interface works without a problem.
> Example code:
> {quote}
> public interface RestResource<T, K> {
> 	T get(K id);
> }
> @Path("test")
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public class TestRestResource implements RestResource<Test, Long> {
> 	public TestRestResource() {
> 	}
> 	@GET
> 	@Path("{id}")
> 	@Override
> 	public Test get(@PathParam("id") Long id) {
> 		return new Test();
> 	}
> }
> {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 issues at jboss.org  Wed Jan  8 05:45:33 2014
From: issues at jboss.org (Philipp Plogmann (JIRA))
Date: Wed, 8 Jan 2014 05:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2724) IllegalArgumentException in
 JAX-RS caused by MethodValidation
In-Reply-To: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528822.1389177240000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528822.1389177240000.34626.1389177933587@jira02.app.mwc.hst.phx2.redhat.com>


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

Philipp Plogmann updated WFLY-2724:
-----------------------------------

    Description: 
If a JaxRS resource implements an interface calls to the interface methods fail with an IllegalArgumentException:

java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)

The same resource class without the interface works without a problem.

Example code:
{quote}

public interface RestResource<T, K> {

	T get(K id);

}

@Path("test")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class TestRestResource implements RestResource<Test, Long> {

	public TestRestResource() {
	}

	@GET
	@Path("{id}")
	@Override
	public Test get(@PathParam("id") Long id) {
		return new Test();
	}

}
{quote}

  was:
If a JaxRS service implements an interface the calls to this method fail with an IllegalArgumentException:

java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)

The same resource class without the interface works without a problem.

Example code:
{quote}

public interface RestResource<T, K> {

	T get(K id);

}

@Path("test")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class TestRestResource implements RestResource<Test, Long> {

	public TestRestResource() {
	}

	@GET
	@Path("{id}")
	@Override
	public Test get(@PathParam("id") Long id) {
		return new Test();
	}

}
{quote}


    
> IllegalArgumentException in JAX-RS caused by MethodValidation
> -------------------------------------------------------------
>
>                 Key: WFLY-2724
>                 URL: https://issues.jboss.org/browse/WFLY-2724
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Philipp Plogmann
>            Assignee: Stuart Douglas
>         Attachments: WildflyRestTest.war, WildflyRestTest.zip
>
>
> If a JaxRS resource implements an interface calls to the interface methods fail with an IllegalArgumentException:
> java.lang.IllegalArgumentException: HV000162: The validated type de.pap.wildflyresttest.TestRestResource$Proxy$_$$_WeldClientProxy does not specify the constructor/method: public de.pap.wildflyresttest.Test de.pap.wildflyresttest.TestRestResource.get(java.lang.Long)
> The same resource class without the interface works without a problem.
> Example code:
> {quote}
> public interface RestResource<T, K> {
> 	T get(K id);
> }
> @Path("test")
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public class TestRestResource implements RestResource<Test, Long> {
> 	public TestRestResource() {
> 	}
> 	@GET
> 	@Path("{id}")
> 	@Override
> 	public Test get(@PathParam("id") Long id) {
> 		return new Test();
> 	}
> }
> {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 issues at jboss.org  Wed Jan  8 06:29:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Jan 2014 06:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Per-deployment descriptor
	replacement
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.34703.1389180572786@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar closed WFLY-2720.
-----------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Rejected


What you want is possible to do with deployment overlays.
see https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays for more info.
                
> Per-deployment descriptor replacement
> -------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently descriptor replacement (ie. in persistence.xml) is possible via system properties.  Unfortunately since system properties are global it is not possible to have per-deployment descriptor replacement.
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements.

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

From issues at jboss.org  Wed Jan  8 06:58:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 06:58:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.34772.1389182312783@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1047519|https://bugzilla.redhat.com/show_bug.cgi?id=1047519] from POST to MODIFIED
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Wed Jan  8 07:00:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 07:00:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.34775.1389182433347@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1038305|https://bugzilla.redhat.com/show_bug.cgi?id=1038305] from POST to MODIFIED
                
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

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

From issues at jboss.org  Wed Jan  8 08:52:34 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Jan 2014 08:52:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-782) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528854.1389189092185@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528854.1389189092185@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528854.1389189092185.34927.1389189154007@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created SECURITY-782:
-------------------------------------

             Summary: EXTC with timeout not properly detected by loadPassword utility in login modules
                 Key: SECURITY-782
                 URL: https://issues.jboss.org/browse/SECURITY-782
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: PicketBox_4_0_20.Beta2
            Reporter: Peter Skopek
            Assignee: Peter Skopek


Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
Example: {EXTC:1000}/usr/bin/getmysecretpwd


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

From issues at jboss.org  Wed Jan  8 08:52:34 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Jan 2014 08:52:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-782) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528854.1389189092000.34931.1389189154513@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek updated SECURITY-782:
----------------------------------

    Affects Version/s: JBossSecurity_2.0.6.Final
                           (was: PicketBox_4_0_20.Beta2)

    
> EXTC with timeout not properly detected by loadPassword utility in login modules
> --------------------------------------------------------------------------------
>
>                 Key: SECURITY-782
>                 URL: https://issues.jboss.org/browse/SECURITY-782
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.6.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>
> Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
> Example: {EXTC:1000}/usr/bin/getmysecretpwd

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

From issues at jboss.org  Wed Jan  8 08:54:32 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Jan 2014 08:54:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-782) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528854.1389189092000.34937.1389189272987@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek updated SECURITY-782:
----------------------------------

    Description: 
This is a backport of SECURITY-780.
Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
Example: {EXTC:1000}/usr/bin/getmysecretpwd


  was:
Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
Example: {EXTC:1000}/usr/bin/getmysecretpwd



    
> EXTC with timeout not properly detected by loadPassword utility in login modules
> --------------------------------------------------------------------------------
>
>                 Key: SECURITY-782
>                 URL: https://issues.jboss.org/browse/SECURITY-782
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.6.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>
> This is a backport of SECURITY-780.
> Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
> Example: {EXTC:1000}/usr/bin/getmysecretpwd

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

From issues at jboss.org  Wed Jan  8 09:00:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 8 Jan 2014 09:00:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1766) NAKACK2/UNICAST3: faster
	acceptance test
In-Reply-To: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528813.1389168082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528813.1389168082000.34948.1389189634154@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1766:
---------------------------

    Comment: was deleted

(was: I need to retract the previous comment: message batches received by NAKACK2 have the same dest: so either all messages in a batch have dest=null or all messages have dest!= null ! So the first comment is still valid and this optimization can be also be done for NAKACK2 !)

    
> NAKACK2/UNICAST3: faster acceptance test
> ----------------------------------------
>
>                 Key: JGRP-1766
>                 URL: https://issues.jboss.org/browse/JGRP-1766
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK2/UNICAST3, when a message batch is received, we check every single message for presence of the corresponding header. If present we accept (and later process) the message.
> A faster acceptance test would be to check if the destination of the message batch matches, e.g.
> * UNICAST3: {{MessageBatch.getDest() != null}}
> * NAKACK2: {{MessageBatch.getDest() == nul}}
> If these conditions are false, we simply pass the batch up. This is faster than iterating through every message in the batch.
> Same for single messages: this is already done in UNICAST3, but not in NAKACK2.

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

From issues at jboss.org  Wed Jan  8 09:18:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 8 Jan 2014 09:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2715) Upgrade to PicketBox
	4.0.20.Beta4
In-Reply-To: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528696.1389055292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528696.1389055292000.34965.1389190712748@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2715.
----------------------------------

    Resolution: Done

    
> Upgrade to PicketBox 4.0.20.Beta4
> ---------------------------------
>
>                 Key: WFLY-2715
>                 URL: https://issues.jboss.org/browse/WFLY-2715
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.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 issues at jboss.org  Wed Jan  8 09:26:33 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Jan 2014 09:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-782) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528854.1389189092000.34974.1389191193178@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek updated SECURITY-782:
----------------------------------

    Fix Version/s: JBossSecurity_2.0.7.Final

    
> EXTC with timeout not properly detected by loadPassword utility in login modules
> --------------------------------------------------------------------------------
>
>                 Key: SECURITY-782
>                 URL: https://issues.jboss.org/browse/SECURITY-782
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.6.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: JBossSecurity_2.0.7.Final
>
>
> This is a backport of SECURITY-780.
> Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
> Example: {EXTC:1000}/usr/bin/getmysecretpwd

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

From issues at jboss.org  Wed Jan  8 09:26:33 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Jan 2014 09:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-782) EXTC with timeout not
 properly detected by loadPassword utility in login modules
In-Reply-To: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528854.1389189092000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528854.1389189092000.34978.1389191193404@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek resolved SECURITY-782.
-----------------------------------

    Resolution: Done

    
> EXTC with timeout not properly detected by loadPassword utility in login modules
> --------------------------------------------------------------------------------
>
>                 Key: SECURITY-782
>                 URL: https://issues.jboss.org/browse/SECURITY-782
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.6.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: JBossSecurity_2.0.7.Final
>
>
> This is a backport of SECURITY-780.
> Using cached external command with time out to get user credential in login modules if not properly detected as to call the external command.
> Example: {EXTC:1000}/usr/bin/getmysecretpwd

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

From issues at jboss.org  Wed Jan  8 09:34:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 09:34:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2536) NPE in cli is thrown when
 using preserve, override without parameter
In-Reply-To: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525558.1384866491000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525558.1384866491000.34995.1389191673041@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1032041|https://bugzilla.redhat.com/show_bug.cgi?id=1032041] from NEW to ASSIGNED
                
> NPE in cli is thrown when using preserve, override without parameter
> --------------------------------------------------------------------
>
>                 Key: WFLY-2536
>                 URL: https://issues.jboss.org/browse/WFLY-2536
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>             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 issues at jboss.org  Wed Jan  8 10:04:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 10:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2633) Cannot use deployments with
 same runtime-name in a domain
In-Reply-To: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527605.1386720363000.35089.1389193472986@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1039699|https://bugzilla.redhat.com/show_bug.cgi?id=1039699] from POST to MODIFIED
                
> Cannot use deployments with same runtime-name in a domain
> ---------------------------------------------------------
>
>                 Key: WFLY-2633
>                 URL: https://issues.jboss.org/browse/WFLY-2633
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The check for duplicate runtime-name in a server group on startup is too aggressive.  It is incorrectly throwing an error on startup if there are any duplicate runtime-names in the whole domain, instead of just in a single server group.
> Steps to Reproduce:
> 1.  Start a single HC/DC
> 2.  deploy --name=foo1 --runtime-name=bar --disabled testfile
> 3.  deploy --name=foo2 --runtime-name=bar --disabled testfile
> 4.  restart the DC/HC
> Actual results:
> JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> ...
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9]
> ...
> Message: JBAS014664: An element of this type named 'bar' has already been declared
> Expected results:
> No errors

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

From issues at jboss.org  Wed Jan  8 10:06:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 10:06:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS /
 Hibernate JPA integration
In-Reply-To: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526628.1385994740000.35095.1389193592907@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1037636|https://bugzilla.redhat.com/show_bug.cgi?id=1037636] from POST to MODIFIED
                
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
>                 Key: WFLY-2593
>                 URL: https://issues.jboss.org/browse/WFLY-2593
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: No Release
>         Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
>            Reporter: Michael Kozak
>            Assignee: Scott Marlow
>            Priority: Critical
>             Fix For: No Release
>
>         Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA. 
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.

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

From issues at jboss.org  Wed Jan  8 10:30:32 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 8 Jan 2014 10:30:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933632@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933632@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933632.35127.1389195032942@jira02.app.mwc.hst.phx2.redhat.com>

Brad Maxwell created WFLY-2725:
----------------------------------

             Summary: Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
                 Key: WFLY-2725
                 URL: https://issues.jboss.org/browse/WFLY-2725
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Server
    Affects Versions: 8.0.0.CR1
            Reporter: Brad Maxwell
            Assignee: Stuart Douglas


'JBAS011046: A component named
'TestBean' is already defined in this module', I have narrowed it
down to it occurs if they have a jar manifest with Class-Path: .
It looks like when deploying it looks at the jar with the manifest
entry which then must be having it scan the jar containing the EJB
again and failing.

Having the Class-Path: . doesn't really make sense to me, however it
also seems like we should not be trying to deploy it twice.

It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib

server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Wed Jan  8 10:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 10:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.35134.1389195153264@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2725:
------------------------------------------

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

    
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Wed Jan  8 10:34:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 10:34:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.35142.1389195274048@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2725:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1049999, https://bugzilla.redhat.com/show_bug.cgi?id=1050003  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1049999)

    
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Wed Jan  8 10:38:34 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jan 2014 10:38:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1063) Improvement: Provide CLI
	preferences
In-Reply-To: <JIRA.12457644.1327596146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457644.1327596146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457644.1327596146000.35154.1389195514945@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved WFLY-1063.
-------------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done


It's implemented in the form of environment variables described here https://community.jboss.org/wiki/CommandLineEnvironmentVariables
                
> Improvement: Provide CLI preferences
> ------------------------------------
>
>                 Key: WFLY-1063
>                 URL: https://issues.jboss.org/browse/WFLY-1063
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Heiko Braun
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> preferences on for default settings:
> [4:37pm] hbraun: CLI preferences would be cool
> [4:37pm] hbraun: i am tired of writing recursive=true all the time
> alias for address tokens:
> [4:38pm] hbraun: plus an address book: prod-db = /subsystem=jadada/database=jadada/
> [4:38pm] hbraun: so you could call prod-db:read-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 issues at jboss.org  Wed Jan  8 10:46:34 2014
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Wed, 8 Jan 2014 10:46:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2684) Security Domains not
 accessible through web console
In-Reply-To: <JIRA.12528395.1387836905000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528395.1387836905000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528395.1387836905000.35171.1389195994489@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-2684:
------------------------------

    Summary: Security Domains not accessible through web console  (was: Security Domains not accessible throught web console)

    
> Security Domains not accessible through web console
> ---------------------------------------------------
>
>                 Key: WFLY-2684
>                 URL: https://issues.jboss.org/browse/WFLY-2684
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux 2.6.32-358.23.2.el6.x86_64 (CentOS 6.4) with 1.7.0_45-mockbuild_2013_10_23_08_18-b00 (OpenJDK  7) or Windows 7 64bit with Oracle Java 7
>            Reporter: Marko Mrvelj
>            Assignee: Heiko Braun
>
> When trying to access Security Domains under Profile/Security tree, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
> Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
> On the same (Linux) machine this works in 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 issues at jboss.org  Wed Jan  8 10:46:35 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jan 2014 10:46:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2644) Java heap space exceeded
 looping connect/disconnect cycle
In-Reply-To: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527822.1386863108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527822.1386863108000.35191.1389195995374@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved WFLY-2644.
-------------------------------------

    Resolution: Done


The CLI fix has been merged into master. Should be fixed now.
                
> Java heap space exceeded looping connect/disconnect cycle
> ---------------------------------------------------------
>
>                 Key: WFLY-2644
>                 URL: https://issues.jboss.org/browse/WFLY-2644
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations.

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

From issues at jboss.org  Wed Jan  8 11:02:33 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jan 2014 11:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-711) Detect/assume duplicate
	instances running
In-Reply-To: <JIRA.12441104.1309876961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12441104.1309876961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441104.1309876961000.35223.1389196953554@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky reassigned WFLY-711:
--------------------------------------

    Assignee:     (was: Alexey Loubyansky)

    
> Detect/assume duplicate instances running
> -----------------------------------------
>
>                 Key: WFLY-711
>                 URL: https://issues.jboss.org/browse/WFLY-711
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Jim Tyrrell
>             Fix For: Awaiting Volunteers
>
>
> I do like the fact that address in use do not leave a running instance laying around, I would much rather see one error message rather then pages and pages.  To our users this is very overwhelming, especially when they come from our competitors.  Also how does this kind of error not have an error code associated with it.
> How many other exceptions do not have error codes?
> Jim-Tyrrells-MacBook-Pro-2:bin jimtyrrell$ ./standalone.sh 
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1
>   JAVA: java
>   JAVA_OPTS: -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
> =========================================================================
> 08:38:37,622 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 08:38:37,772 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 08:38:37,812 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 08:38:38,328 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 08:38:38,333 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 08:38:38,343 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 08:38:38,413 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 08:38:38,420 INFO  [org.jboss.as.naming] (MSC service thread 1-4) Starting Naming Service 
> 08:38:38,425 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 08:38:38,436 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 08:38:38,442 INFO  [org.jboss.remoting] (MSC service thread 1-10) JBoss Remoting version 3.2.0.Beta2
> 08:38:38,448 INFO  [org.xnio] (MSC service thread 1-10) XNIO Version 3.0.0.Beta3
> 08:38:38,457 INFO  [org.xnio.nio] (MSC service thread 1-10) XNIO NIO Implementation Version 3.0.0.Beta3
> 08:38:38,606 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
> 08:38:38,616 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-10) Starting remote JMX connector
> 08:38:38,618 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 08:38:38,618 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.remoting.server.management.9999: org.jboss.msc.service.StartException in service jboss.remoting.server.management.9999: java.net.BindException: Address already in use
> 	at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:98)
> 	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:680) [:1.6.0_24]
> Caused by: java.net.BindException: Address already in use
> 	at sun.nio.ch.Net.bind(Native Method) [:1.6.0_24]
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [:1.6.0_24]
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [:1.6.0_24]
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) [:1.6.0_24]
> 	at org.xnio.nio.NioXnio.createTcpServer(NioXnio.java:162)
> 	at org.xnio.Xnio.createStreamServer(Xnio.java:230)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:162)
> 	at org.jboss.as.remoting.AbstractStreamServerService.start(AbstractStreamServerService.java:93)
> 	... 5 more
> 08:38:38,623 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-6) Unable to set the URLStreamHandlerFactory
> 08:38:38,624 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-6) Unable to set the ContentHandlerFactory
> 08:38:38,625 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) 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:89)
> 	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:680) [:1.6.0_24]
> Caused by: java.net.BindException: Address already in use
> 	at sun.nio.ch.Net.bind(Native Method) [:1.6.0_24]
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) [:1.6.0_24]
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) [:1.6.0_24]
> 	at org.jboss.sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:112)
> 	at org.jboss.sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:47)
> 	at org.jboss.sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:37)
> 	at org.jboss.com.sun.net.httpserver.HttpServer.create(HttpServer.java:126)
> 	at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:99)
> 	at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:86)
> 	... 5 more
> 08:38:38,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC00001: Failed to start service jboss.mbean.connector: org.jboss.msc.service.StartException in service jboss.mbean.connector: java.rmi.server.ExportException: Port already in use: 1090; nested exception is: 
> 	java.net.BindException: Address already in use
> 	at org.jboss.as.jmx.JMXConnectorService.start(JMXConnectorService.java:106)
> 	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:680) [:1.6.0_24]
> Caused by: java.rmi.server.ExportException: Port already in use: 1090; nested exception is: 
> 	java.net.BindException: Address already in use
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310) [:1.6.0_24]
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218) [:1.6.0_24]
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) [:1.6.0_24]
> 	at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) [:1.6.0_24]
> 	at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190) [:1.6.0_24]
> 	at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92) [:1.6.0_24]
> 	at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:68) [:1.6.0_24]
> 	at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222) [:1.6.0_24]
> 	at org.jboss.as.jmx.JMXConnectorService.start(JMXConnectorService.java:97)
> 	... 5 more
> Caused by: java.net.BindException: Address already in use
> 	at java.net.PlainSocketImpl.socketBind(Native Method) [:1.6.0_24]
> 	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) [:1.6.0_24]
> 	at java.net.ServerSocket.bind(ServerSocket.java:328) [:1.6.0_24]
> 	at org.jboss.as.network.ManagedServerSocketBinding.bind(ManagedServerSocketBinding.java:73)
> 	at org.jboss.as.network.SocketBinding.createServerSocket(SocketBinding.java:149)
> 	at org.jboss.as.jmx.JMXConnectorService$JMXServerSocketFactory.createServerSocket(JMXConnectorService.java:194)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649) [:1.6.0_24]
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299) [:1.6.0_24]
> 	... 13 more
> 08:38:38,634 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-13) Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
> 	at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:1004)
> 	at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:190)
> 	at org.apache.catalina.connector.Connector.init(Connector.java:976)
> 	at org.apache.catalina.core.StandardService.addConnector(StandardService.java:351)
> 	at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> 	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> 	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:680) [:1.6.0_24]
> 08:38:38,636 ERROR [org.apache.catalina.core.StandardService] (MSC service thread 1-13) Connector.initialize: LifecycleException:  Protocol handler initialization failed: java.net.BindException: Address already in use /127.0.0.1:8080
> 	at org.apache.catalina.connector.Connector.init(Connector.java:978)
> 	at org.apache.catalina.core.StandardService.addConnector(StandardService.java:351)
> 	at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> 	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> 	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:680) [:1.6.0_24]
> 08:38:38,638 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-13) Error starting endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
> 	at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:1004)
> 	at org.apache.tomcat.util.net.JIoEndpoint.start(JIoEndpoint.java:1020)
> 	at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:218)
> 	at org.apache.catalina.connector.Connector.start(Connector.java:1051)
> 	at org.apache.catalina.core.StandardService.addConnector(StandardService.java:359)
> 	at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> 	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> 	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:680) [:1.6.0_24]
> 08:38:38,639 ERROR [org.apache.catalina.core.StandardService] (MSC service thread 1-13) Connector.start: LifecycleException:  service.getName(): "jboss.web";  Protocol handler start failed: java.net.BindException: Address already in use /127.0.0.1:8080
> 	at org.apache.catalina.connector.Connector.start(Connector.java:1058)
> 	at org.apache.catalina.core.StandardService.addConnector(StandardService.java:359)
> 	at org.jboss.as.web.WebServerService.addConnector(WebServerService.java:121)
> 	at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:223)
> 	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:680) [:1.6.0_24]
> 08:38:38,675 INFO  [org.jboss.as.connector] (MSC service thread 1-6) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 08:38:38,700 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-12) Bound data source [java:jboss/datasources/ExampleDS]
> 08:38:38,920 INFO  [org.jboss.as.deployment] (MSC service thread 1-10) Started FileSystemDeploymentService for directory /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments
> 08:38:39,130 INFO  [org.jboss.as.controller] (Controller Boot Thread) Service status report
>   Services which failed to start:
>       service jboss.remoting.server.management.9999: org.jboss.msc.service.StartException in service jboss.remoting.server.management.9999: java.net.BindException: Address already in use
>       service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
>       service jboss.mbean.connector: org.jboss.msc.service.StartException in service jboss.mbean.connector: java.rmi.server.ExportException: Port already in use: 1090; nested exception is: 
> 	java.net.BindException: Address already in use
> 08:38:39,134 ERROR [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started (with errors) in 1668ms - Started 87 of 146 services (4 services failed or missing dependencies, 55 services are passive or on-demand)
> ^C08:39:03,929 INFO  [org.jboss.as.logging] Restored bootstrap log handlers
> 08:39:03,933 INFO  [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 08:39:03,933 INFO  [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 08:39:03,934 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" stopped in 4ms

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

From issues at jboss.org  Wed Jan  8 11:06:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 11:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2521) EJB backing cache's can
 generate large retention from cancelled tasks in its scheduled executor's
 DelayedWorkQueue
In-Reply-To: <JIRA.12525362.1384551061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525362.1384551061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525362.1384551061000.35233.1389197193474@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1031199|https://bugzilla.redhat.com/show_bug.cgi?id=1031199] from POST to MODIFIED
                
> EJB backing cache's can generate large retention from cancelled tasks in its scheduled executor's DelayedWorkQueue
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2521
>                 URL: https://issues.jboss.org/browse/WFLY-2521
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> EJB backing cache's frequently cancel remove and passivation tasks with each access and replace them with new ones.  Per http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html cancelled tasks are not removed from queue until their scheduled delay passes.
> So due to the java ScheduledThreadPoolExecutor's lazy cancelled task removal, this scheduled task cancellation and recreation model can potentially churn up quite a number of queued cancelled tasks sitting in the executor's DelayedWorkQueue.  With longer timeouts and frequent ejb access, this can generate substantial heap overhead.
> It should be pretty easy to help limit any such build up by calling purge() [1] on the scheduled executor.  Likely don't want to purge with each cancel, so perhaps a purge() could be called on a configurable time delay or after a configurable amount of cancels?
> [1] http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html#purge%28%29

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

From issues at jboss.org  Wed Jan  8 12:28:32 2014
From: issues at jboss.org (Leandro Kersting de Freitas (JIRA))
Date: Wed, 8 Jan 2014 12:28:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2726) Update JSF based on Mojarra
	2.2.5 final
In-Reply-To: <JIRA.12528881.1389202100831@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528881.1389202100831@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528881.1389202100831.35336.1389202112868@jira02.app.mwc.hst.phx2.redhat.com>

Leandro Kersting de Freitas created WFLY-2726:
-------------------------------------------------

             Summary: Update JSF based on Mojarra 2.2.5 final
                 Key: WFLY-2726
                 URL: https://issues.jboss.org/browse/WFLY-2726
             Project: WildFly
          Issue Type: Library Upgrade
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Leandro Kersting de Freitas
             Fix For: 8.0.0.Final


Update JSF based on Mojarra 2.2.5 final.

https://javaserverfaces.java.net/nonav/2.2/releasenotes.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 issues at jboss.org  Wed Jan  8 12:32:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Jan 2014 12:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2726) Update JSF based on Mojarra
	2.2.5 final
In-Reply-To: <JIRA.12528881.1389202100000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528881.1389202100000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528881.1389202100000.35339.1389202353536@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2726:
------------------------------

    Component/s: JSF

    
> Update JSF based on Mojarra 2.2.5 final
> ---------------------------------------
>
>                 Key: WFLY-2726
>                 URL: https://issues.jboss.org/browse/WFLY-2726
>             Project: WildFly
>          Issue Type: Library Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Leandro Kersting de Freitas
>             Fix For: 8.0.0.Final
>
>
> Update JSF based on Mojarra 2.2.5 final.
> https://javaserverfaces.java.net/nonav/2.2/releasenotes.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 issues at jboss.org  Wed Jan  8 12:32:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 12:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1186) Create JPA service callback
 for invoking database migration
In-Reply-To: <JIRA.12482460.1357949063000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482460.1357949063000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482460.1357949063000.35344.1389202353840@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-1186:
-------------------------------

    Assignee:     (was: Scott Marlow)

    
> Create JPA service callback for invoking database migration
> -----------------------------------------------------------
>
>                 Key: WFLY-1186
>                 URL: https://issues.jboss.org/browse/WFLY-1186
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Anil Arora
>
> Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism.
> Ideally, there would be a property within the persistence.xml that indicates which class to call.  It would also pass in/inject the datasource that is being used for the persistence unit. 
> Essentially, this would solve the lack of migration support in Hibernate itself.

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


From issues at jboss.org  Wed Jan  8 12:32:34 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Jan 2014 12:32:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2726) Update JSF based on Mojarra
	2.2.5 final
In-Reply-To: <JIRA.12528881.1389202100000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528881.1389202100000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528881.1389202100000.35347.1389202354050@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-2726:
---------------------------------

    Assignee: Farah Juma

    
> Update JSF based on Mojarra 2.2.5 final
> ---------------------------------------
>
>                 Key: WFLY-2726
>                 URL: https://issues.jboss.org/browse/WFLY-2726
>             Project: WildFly
>          Issue Type: Library Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Leandro Kersting de Freitas
>            Assignee: Farah Juma
>             Fix For: 8.0.0.Final
>
>
> Update JSF based on Mojarra 2.2.5 final.
> https://javaserverfaces.java.net/nonav/2.2/releasenotes.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 issues at jboss.org  Wed Jan  8 12:50:33 2014
From: issues at jboss.org (arjan tijms (JIRA))
Date: Wed, 8 Jan 2014 12:50:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353273@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353273@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353273.35381.1389203433364@jira02.app.mwc.hst.phx2.redhat.com>

arjan tijms created WFLY-2727:
---------------------------------

             Summary: @DataSourceDefinition defined data source can't be used in persistence.xml
                 Key: WFLY-2727
                 URL: https://issues.jboss.org/browse/WFLY-2727
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE, JPA / Hibernate
    Affects Versions: 8.0.0.CR1
            Reporter: arjan tijms
            Assignee: David Lloyd


Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.

E.g.

{code:xml|title=web.xml}
<data-source>
    <name>java:app/MyApp/MyDS</name>
    <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
    <url>jdbc:h2:mem:test</url>
</data-source>
{code}

and

{code:xml|title=persistence.xml}
<persistence-unit name="testPU">
    <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
</persistence-unit>
{code}

will result in:

{noformat}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}

ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
{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 issues at jboss.org  Wed Jan  8 12:56:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 12:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35391.1389203793263@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow reassigned WFLY-2727:
----------------------------------

    Assignee: Scott Marlow  (was: David Lloyd)

    
> @DataSourceDefinition defined data source can't be used in persistence.xml
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 13:00:32 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 13:00:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35403.1389204032855@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2727:
------------------------------------

Its a timing issue.  By default, we use the persistence unit definition before the @DataSourceDefinition is available as for various timing reasons.  Could you check if adding persistence unit (hint) property "wildfly.jpa.twophasebootstrap" set to false, works around the failure.

>From https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties:
{quote}
persistence providers (like Hibernate ORM 4.3.x via EntityManagerFactoryBuilder), allow a two phase persistence unit bootstrap, which improves JPA integration with CDI.  Setting the wildfly.jpa.twophasebootstrap hint to false, disables the two phase bootstrap (for the persistence unit that contains the hint). 
{quote}
                
> @DataSourceDefinition defined data source can't be used in persistence.xml
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 13:08:33 2014
From: issues at jboss.org (arjan tijms (JIRA))
Date: Wed, 8 Jan 2014 13:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35408.1389204513782@jira02.app.mwc.hst.phx2.redhat.com>


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

arjan tijms commented on WFLY-2727:
-----------------------------------

{quote}Could you check if adding persistence unit (hint) property "wildfly.jpa.twophasebootstrap" set to false, works around the failure.{quote}

Yes, adding {{<property name="wildfly.jpa.twophasebootstrap" value="false" />}} indeed works around the failure for both cases (data source defined with annotation and in web.xml). With that property set the tests pass successfully.

But the side effect of this property is reduced integration with CDI?
                
> @DataSourceDefinition defined data source can't be used in persistence.xml
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 13:10:32 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 13:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35421.1389204632736@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow edited comment on WFLY-2727 at 1/8/14 1:10 PM:
------------------------------------------------------------

Its a timing issue.  By default, we use the persistence unit definition before the @DataSourceDefinition is available as for various timing reasons.  If we wait for the DataSourceDefinition to be available, we can't use CDI (application classloader will have been used by that point).

Could you check if adding persistence unit (hint) property "wildfly.jpa.twophasebootstrap" set to false, works around the failure.  

>From https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties:
{quote}
persistence providers (like Hibernate ORM 4.3.x via EntityManagerFactoryBuilder), allow a two phase persistence unit bootstrap, which improves JPA integration with CDI.  Setting the wildfly.jpa.twophasebootstrap hint to false, disables the two phase bootstrap (for the persistence unit that contains the hint). 
{quote}
                
      was (Author: smarlow):
    Its a timing issue.  By default, we use the persistence unit definition before the @DataSourceDefinition is available as for various timing reasons.  Could you check if adding persistence unit (hint) property "wildfly.jpa.twophasebootstrap" set to false, works around the failure.

>From https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties:
{quote}
persistence providers (like Hibernate ORM 4.3.x via EntityManagerFactoryBuilder), allow a two phase persistence unit bootstrap, which improves JPA integration with CDI.  Setting the wildfly.jpa.twophasebootstrap hint to false, disables the two phase bootstrap (for the persistence unit that contains the hint). 
{quote}
                  
> @DataSourceDefinition defined data source can't be used in persistence.xml
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 13:26:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 13:26:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35447.1389205593231@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2727:
------------------------------------

Yes, if applications use both a @DataSourceDefinition and entity class listeners that use CDI, they will not work correctly.  There is a Hibernate change that we have discussed that will help in the future (so at least Hibernate will work correctly).

There was some discussion here [https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/thread/1#00000] about the two phase persistence unit bootstrap idea.  I think that this will be addressed when all persistence providers implement a 2-phase bootstrap approach to starting the EntityManagerFactory and defer use of the datasource until the second phase.  Currently, Hibernate uses the datasource in the phase boot strap phase.  Note that we implemented an extension in Hibernate to allow the persistence unit to be created in two phases.  When/if the extension is standardized as part of some future JPA spec release, hopefully we will have all persistence providers (in their new releases) implementing it.




                
> @DataSourceDefinition defined data source can't be used in persistence.xml
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 13:34:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 13:34:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35459.1389206073184@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow edited comment on WFLY-2727 at 1/8/14 1:32 PM:
------------------------------------------------------------

Yes, if applications use both a @DataSourceDefinition and entity class listeners that use CDI, they will not work correctly.  There is a Hibernate change that we have discussed that will help in the future (so at least Hibernate will work correctly).

There was some discussion here [https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/thread/1#00000] about the two phase persistence unit bootstrap idea.  I think that this will be addressed when all persistence providers implement a 2-phase bootstrap approach to starting the EntityManagerFactory and defer use of the datasource until the second phase.  Currently, Hibernate uses the datasource in the *first* boot strap phase.  Note that we implemented an extension in Hibernate to allow the persistence unit to be created in two phases.  When/if the extension is standardized as part of some future JPA spec release, hopefully we will have all persistence providers (in their new releases) implementing it.




                
      was (Author: smarlow):
    Yes, if applications use both a @DataSourceDefinition and entity class listeners that use CDI, they will not work correctly.  There is a Hibernate change that we have discussed that will help in the future (so at least Hibernate will work correctly).

There was some discussion here [https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/thread/1#00000] about the two phase persistence unit bootstrap idea.  I think that this will be addressed when all persistence providers implement a 2-phase bootstrap approach to starting the EntityManagerFactory and defer use of the datasource until the second phase.  Currently, Hibernate uses the datasource in the phase boot strap phase.  Note that we implemented an extension in Hibernate to allow the persistence unit to be created in two phases.  When/if the extension is standardized as part of some future JPA spec release, hopefully we will have all persistence providers (in their new releases) implementing it.




                  
> @DataSourceDefinition defined data source can't be used in persistence.xml
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 13:44:33 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 8 Jan 2014 13:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2728) JASPIAuthenticationMechanism
 doesn't handle wrapped/unwrapped request and response objects
In-Reply-To: <JIRA.12528894.1389206581654@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528894.1389206581654@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528894.1389206581654.35468.1389206673116@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created WFLY-2728:
------------------------------------

             Summary: JASPIAuthenticationMechanism doesn't handle wrapped/unwrapped request and response objects
                 Key: WFLY-2728
                 URL: https://issues.jboss.org/browse/WFLY-2728
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.CR1
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: 8.0.0.Final


JASPIAuthenticationMechanims must check if a SAM has wrapped (during validateRequest) or unwrapped (during secureResponse) the HTTP request and response objects and replace the original references by the wrapped/unwrapped ones before continuing with the request processing.

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

From issues at jboss.org  Wed Jan  8 14:18:32 2014
From: issues at jboss.org (pugal srini (JIRA))
Date: Wed, 8 Jan 2014 14:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9555) CDI fails in multiple war
 inside ear - depends on war name
In-Reply-To: <JIRA.12528898.1389208613011@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528898.1389208613011@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528898.1389208613011.35484.1389208712716@jira02.app.mwc.hst.phx2.redhat.com>

pugal srini created JBAS-9555:
---------------------------------

             Summary: CDI fails in multiple war inside ear - depends on war name
                 Key: JBAS-9555
                 URL: https://issues.jboss.org/browse/JBAS-9555
             Project: Application Server 3  4  5 and 6
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Weld/CDI
    Affects Versions: 6.1.0
            Reporter: pugal srini
            Assignee: Marius Bogoevici


CDI injection fails (is null) in a war when the ear contains more than one war file. The CDI succeeds/fails based on which war gets deployed first. If the any of the failed war is deployed alone, it succeeds. 
This issue does not happen in jboss AS 7 or 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 issues at jboss.org  Wed Jan  8 14:24:32 2014
From: issues at jboss.org (pugal srini (JIRA))
Date: Wed, 8 Jan 2014 14:24:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9555) CDI fails in multiple war
 inside ear - depends on war name
In-Reply-To: <JIRA.12528898.1389208613000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528898.1389208613000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528898.1389208613000.35491.1389209072773@jira02.app.mwc.hst.phx2.redhat.com>


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

pugal srini updated JBAS-9555:
------------------------------

    Attachment: helloworld.zip


This is a maven project.
                
> CDI fails in multiple war inside ear - depends on war name
> ----------------------------------------------------------
>
>                 Key: JBAS-9555
>                 URL: https://issues.jboss.org/browse/JBAS-9555
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Weld/CDI
>    Affects Versions: 6.1.0
>            Reporter: pugal srini
>            Assignee: Marius Bogoevici
>              Labels: ear, injection, war, weld
>         Attachments: helloworld.zip
>
>
> CDI injection fails (is null) in a war when the ear contains more than one war file. The CDI succeeds/fails based on which war gets deployed first. If the any of the failed war is deployed alone, it succeeds. 
> This issue does not happen in jboss AS 7 or 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 issues at jboss.org  Wed Jan  8 14:24:32 2014
From: issues at jboss.org (pugal srini (JIRA))
Date: Wed, 8 Jan 2014 14:24:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9555) CDI fails in multiple war
 inside ear - depends on war name
In-Reply-To: <JIRA.12528898.1389208613000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528898.1389208613000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528898.1389208613000.35494.1389209072954@jira02.app.mwc.hst.phx2.redhat.com>


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

pugal srini updated JBAS-9555:
------------------------------

    Steps to Reproduce: 
The project build files are attached.
Have two wars with a Servlet injecting a regular POJO from the same war (HelloWorldServlet injecting HelloWorld class)
Deploy the ear that contains hello.war and goodbye.war.
The log shows that only one bean is injected - only HelloWorld is injected and Goodbye is null.
Now rename (or rebuild the ear with one war name changed) one of the war so that it is in different sorted order. (say hello.war to ahello.war or goodbye.war zgoodbye.war). When redeployed, now the HelloWorld is null and Goodbye is injected.
 
The project structure is as follows.
The maven source to build the project is attached.
 
hello_EAR.ear
    +META-INF
        application.xml
    +hello.war
        +WEB-INF
            classes
                com.hello.HelloWorldServlet.class
                com.hello.HelloWorld.class
            web.xml
            beans.xml
         META-INF
     +goodbye.war
          +WEB-INF
           classes
                com.hello.GoodbyeWorldServlet.class
                com.hello.GoodbyeWorld.class
           web.xml
           beans.xml
        +META-INF

  was:
The project build files are in 
https://community.jboss.org/thread/235933
Have two wars with a Servlet injecting a regular POJO from the same war (HelloWorldServlet injecting HelloWorld class)
Deploy the ear that contains hello.war and goodbye.war.
The log shows that only one bean is injected - only HelloWorld is injected and Goodbye is null.
Now rename (or rebuild the ear with one war name changed) one of the war so that it is in different sorted order. (say hello.war to ahello.war or goodbye.war zgoodbye.war). When redeployed, now the HelloWorld is null and Goodbye is injected.
 
The project structure is as follows.
The maven source to build the project is attached.
 
hello_EAR.ear
    +META-INF
        application.xml
    +hello.war
        +WEB-INF
            classes
                com.hello.HelloWorldServlet.class
                com.hello.HelloWorld.class
            web.xml
            beans.xml
         META-INF
     +goodbye.war
          +WEB-INF
           classes
                com.hello.GoodbyeWorldServlet.class
                com.hello.GoodbyeWorld.class
           web.xml
           beans.xml
        +META-INF


    
> CDI fails in multiple war inside ear - depends on war name
> ----------------------------------------------------------
>
>                 Key: JBAS-9555
>                 URL: https://issues.jboss.org/browse/JBAS-9555
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Weld/CDI
>    Affects Versions: 6.1.0
>            Reporter: pugal srini
>            Assignee: Marius Bogoevici
>              Labels: ear, injection, war, weld
>         Attachments: helloworld.zip
>
>
> CDI injection fails (is null) in a war when the ear contains more than one war file. The CDI succeeds/fails based on which war gets deployed first. If the any of the failed war is deployed alone, it succeeds. 
> This issue does not happen in jboss AS 7 or 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 issues at jboss.org  Wed Jan  8 15:48:32 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 15:48:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml with CDI entity listeners
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35548.1389214112782@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2727:
-------------------------------

    Summary: @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners  (was: @DataSourceDefinition defined data source can't be used in persistence.xml)

    
> @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 15:50:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 15:50:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml with CDI entity listeners
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35551.1389214233164@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2727:
-------------------------------

    Workaround Description: see [comment|https://issues.jboss.org/browse/WFLY-2727?focusedCommentId=12934540&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12934540]

    
> @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 16:08:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 16:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml with CDI entity listeners
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35565.1389215313226@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2727:
------------------------------------

I changed the original description to add "with CDI entity listeners", to reflect that you cannot use both CDI-JPA features and @DataSourceDefinition from the same application.

Regarding the comment on JAVAEE_SPEC-30 about vendors not wanting to support @DataSourceDefinition.  I don't know if its that as much as there being room for improvement.  If we add a standardized two-phase persistence unit bootstrap that doesn't use the Datasource or CDI beanmanager until the second PU boot phase, we will see fewer integration problems between the different technologies (CDI/@DataSourceDefinitiion) and JPA.  
                
> @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 16:28:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 16:28:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.35599.1389216512825@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated JBWEB-282:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022634, https://bugzilla.redhat.com/show_bug.cgi?id=1022777, https://bugzilla.redhat.com/show_bug.cgi?id=1050225  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1022634, https://bugzilla.redhat.com/show_bug.cgi?id=1022777)

    
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

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

From issues at jboss.org  Wed Jan  8 16:38:33 2014
From: issues at jboss.org (Abraham Tehrani (JIRA))
Date: Wed, 8 Jan 2014 16:38:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBBUILD-733) 503 returned from
 repository.jboss.org intermittently
In-Reply-To: <JIRA.12528909.1389217111016@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528909.1389217111016@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528909.1389217111016.35602.1389217113169@jira02.app.mwc.hst.phx2.redhat.com>

Abraham Tehrani created JBBUILD-733:
---------------------------------------

             Summary: 503 returned from repository.jboss.org intermittently
                 Key: JBBUILD-733
                 URL: https://issues.jboss.org/browse/JBBUILD-733
             Project: JBoss Build System
          Issue Type: Bug
            Reporter: Abraham Tehrani
            Assignee: Paul Gier


It appears that the repository.jboss.org briefly goes down, which causes our internal maven repo to autoblock it, cause our builds to fail. This was never an issue, but it seems to be occurring more frequently. Is this something you can verify on your end that the host has been up/down? Thanks!

Repository proxy mode change
Tue 7:40 am
The proxy mode of repository 'Jboss-Org' (ID='Jboss-Org') was set to Blocked (auto). The previous state was Allow. Last detected transport error: The method execution returned result code 503. [repositoryId="Jboss-Org", requestPath="/org/apache/httpcomponents/httpcore/4.1.4/httpcore-4.1.4.pom", remoteUrl="https://repository.jboss.org/nexus/content/groups/public/org/apache/httpcomponents/httpcor...


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

From issues at jboss.org  Wed Jan  8 16:44:33 2014
From: issues at jboss.org (Paa Kojo Konduah Amos (JIRA))
Date: Wed, 8 Jan 2014 16:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366973@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366973@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366973.35608.1389217473261@jira02.app.mwc.hst.phx2.redhat.com>

Paa Kojo Konduah Amos created WFLY-2729:
-------------------------------------------

             Summary: Exception thrown, when you try to clean server
                 Key: WFLY-2729
                 URL: https://issues.jboss.org/browse/WFLY-2729
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
         Environment: Ubuntu Linux
            Reporter: Paa Kojo Konduah Amos
            Assignee: Stuart Douglas
             Fix For: 8.0.0.CR1


when you right clean on Server to clean it. it throws 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 issues at jboss.org  Wed Jan  8 16:58:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Jan 2014 16:58:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.35623.1389218312843@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-2729:
-----------------------------------

What is the exception? what is the context?
Are we talking about some IDE?
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Wed Jan  8 17:06:32 2014
From: issues at jboss.org (arjan tijms (JIRA))
Date: Wed, 8 Jan 2014 17:06:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml with CDI entity listeners
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35626.1389218792770@jira02.app.mwc.hst.phx2.redhat.com>


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

arjan tijms commented on WFLY-2727:
-----------------------------------

{quote}Note that we implemented an extension in Hibernate to allow the persistence unit to be created in two phases. When/if the extension is standardized as part of some future JPA spec release, hopefully we will have all persistence providers (in their new releases) implementing it.{quote}

Maybe I don't fully understand, but since Hibernate is used by WildFly and part of the JBoss community, what is stopping things from working out of the box now? Or is the extension you mention for a version of Hibernate newer than what WildFly is currently using?

{quote}to reflect that you cannot use both CDI-JPA features and @DataSourceDefinition from the same application.{quote}

Okay, so that's indeed more clear. But practically speaking there's also the issue now that users have to add the above mentioned property, isn't there? Since {{@DataSourceDefinition}} is largely an ease-of-use feature, this may be a bit problematic for exactly those users who are the intended target. If the issue can't be solved otherwise for the short term, would it be an option to provide a hint to the user when logging the error that this property needs to be set?

{quote}Regarding the comment on JAVAEE_SPEC-30 about vendors not wanting to support @DataSourceDefinition.{quote}

Well the comment wasn't so much about vendors not wanting to support it (for whatever reason), but more that I got the impression that some of them were genuinely surprised that such data source also had to work with JPA. The spec only talks about injecting it via {{@Resource}}, so there may be some room for clarification there.

There is at least 1 vendor if I'm not mistaken who seems to be against any kind of administered object inside an archive (including JMS destinations, email sessions, JASPIC security modules, data sources and what have you), but that's an entirely different story ;)

{quote} If we add a standardized two-phase persistence unit bootstrap that doesn't use the Datasource or CDI beanmanager until the second PU boot phase, we will see fewer integration problems between the different technologies (CDI/@DataSourceDefinitiion) and JPA. {quote}

This sounds like a very important improvement indeed and certainly worth it to create a JIRA issue on the JPA tracker for.
 



                
> @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 17:08:33 2014
From: issues at jboss.org (Paa Kojo Konduah Amos (JIRA))
Date: Wed, 8 Jan 2014 17:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.35630.1389218913489@jira02.app.mwc.hst.phx2.redhat.com>


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

Paa Kojo Konduah Amos commented on WFLY-2729:
---------------------------------------------

22:06:55,573 WARN  [io.undertow.servlet] (MSC service thread 1-1) UT015008: Failed to load development mode persistent sessions: java.lang.ClassNotFoundException: /BeanManagerImplanageriltin/BeanManage

Eclipse Kepler, Deltaspike.
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Wed Jan  8 17:20:33 2014
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Wed, 8 Jan 2014 17:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1383) Disable pooling of stateless
 EJBs by default
In-Reply-To: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492528.1369290890000.35639.1389219633775@jira02.app.mwc.hst.phx2.redhat.com>


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

Cheng Fang updated WFLY-1383:
-----------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/4542, https://github.com/wildfly/wildfly/pull/5688  (was: https://github.com/wildfly/wildfly/pull/4542)

    
> Disable pooling of stateless EJBs by default
> --------------------------------------------
>
>                 Key: WFLY-1383
>                 URL: https://issues.jboss.org/browse/WFLY-1383
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Cheng Fang
>
> A certain use case has shown that it's perhaps better to disable pooling of EJB stateless bean, by default. In AS7 we have always allowed disabling the pooling but we hadn't made it the default since we thought it might affect applications which have SLSBs with heavy @PostConstruct.
> A recent discussion has suggested that we disable the pooling by default and individual applications can enable it and set the relevant pool size themselves. The reasoning has been that, the default pool size that we ship with, anyway will have to be tweaked by the users since we can't really guess what an ideal pool size 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 issues at jboss.org  Wed Jan  8 18:04:32 2014
From: issues at jboss.org (Patson Luk (JIRA))
Date: Wed, 8 Jan 2014 18:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-210) MethodCall.replace() throws
 inconsistent stack height in certain scenarios
In-Reply-To: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502614.1381349908000.35657.1389222272859@jira02.app.mwc.hst.phx2.redhat.com>


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

Patson Luk commented on JASSIST-210:
------------------------------------

Many thanks for the detailed reply!

There is still one piece that I do not quite understand, would please please kindly elaborate?

You mentioned that after the translation 2 and 3 are replaced with a try-catch statement, but in the sample code, the replacement block $_ = $proceed($$) itself is NOT surrounded by try-catch, only the injected System.out... was surrounded by try-catch:

 "{ try
{ System.out.println(\"injected\"); }

catch (Exception e)
{ e.printStackTrace(); }

$_ = $proceed($$); }";

Therefore, if $_ = $proceed($$) does throw exception, it should still follow the same flow as if there is no try-catch? (as that piece of the code is not really wrapped)

Many thanks for your clarification in advanced
                
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
>                 Key: JASSIST-210
>                 URL: https://issues.jboss.org/browse/JASSIST-210
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA, 3.18.1-GA
>            Reporter: Patson Luk
>            Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial,  the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
>     public void edit(MethodCall m) throws CannotCompileException {
>         if (m.getMethodName().equals("testMethod2")) {
>             String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
>             m.replace(newBlock);
>         }
>     }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
>     public static void main(String[] args) {
>         RefClass ref = new RefClass();
>         ref.testMethod2();
>     }
> }
> class RefClass {
>     public void testMethod1(Object o) {}
>     public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!

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

From issues at jboss.org  Wed Jan  8 18:04:33 2014
From: issues at jboss.org (Patson Luk (JIRA))
Date: Wed, 8 Jan 2014 18:04:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-210) MethodCall.replace() throws
 inconsistent stack height in certain scenarios
In-Reply-To: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502614.1381349908000.35659.1389222273014@jira02.app.mwc.hst.phx2.redhat.com>


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

Patson Luk edited comment on JASSIST-210 at 1/8/14 6:03 PM:
------------------------------------------------------------

Many thanks for the detailed reply!

There is still one piece that I do not quite understand, would you please kindly elaborate?

You mentioned that after the translation 2 and 3 are replaced with a try-catch statement, but in the sample code, the replacement block $_ = $proceed($$) itself is NOT surrounded by try-catch, only the injected System.out... was surrounded by try-catch:

 "{ try
{ System.out.println(\"injected\"); }

catch (Exception e)
{ e.printStackTrace(); }

$_ = $proceed($$); }";

Therefore, if $_ = $proceed($$) does throw exception, it should still follow the same flow as if there is no try-catch? (as that piece of the code is not really wrapped)

Many thanks for your clarification in advanced
                
      was (Author: pluk):
    Many thanks for the detailed reply!

There is still one piece that I do not quite understand, would please please kindly elaborate?

You mentioned that after the translation 2 and 3 are replaced with a try-catch statement, but in the sample code, the replacement block $_ = $proceed($$) itself is NOT surrounded by try-catch, only the injected System.out... was surrounded by try-catch:

 "{ try
{ System.out.println(\"injected\"); }

catch (Exception e)
{ e.printStackTrace(); }

$_ = $proceed($$); }";

Therefore, if $_ = $proceed($$) does throw exception, it should still follow the same flow as if there is no try-catch? (as that piece of the code is not really wrapped)

Many thanks for your clarification in advanced
                  
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
>                 Key: JASSIST-210
>                 URL: https://issues.jboss.org/browse/JASSIST-210
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA, 3.18.1-GA
>            Reporter: Patson Luk
>            Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial,  the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
>     public void edit(MethodCall m) throws CannotCompileException {
>         if (m.getMethodName().equals("testMethod2")) {
>             String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
>             m.replace(newBlock);
>         }
>     }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
>     public static void main(String[] args) {
>         RefClass ref = new RefClass();
>         ref.testMethod2();
>     }
> }
> class RefClass {
>     public void testMethod1(Object o) {}
>     public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!

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

From issues at jboss.org  Wed Jan  8 18:17:32 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Wed, 8 Jan 2014 18:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001743@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001743@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001743.35663.1389223052696@jira02.app.mwc.hst.phx2.redhat.com>

leonardo lizana created DROOLS-394:
--------------------------------------

             Summary: java.lang.RuntimeException: cannot invoke getter
                 Key: DROOLS-394
                 URL: https://issues.jboss.org/browse/DROOLS-394
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: leonardo lizana
            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 issues at jboss.org  Wed Jan  8 18:21:33 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Wed, 8 Jan 2014 18:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001000.35666.1389223293090@jira02.app.mwc.hst.phx2.redhat.com>


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

leonardo lizana updated DROOLS-394:
-----------------------------------

    Description: 
this is the log error:
----------------------------

java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
        at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
        at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
        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:337)
        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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
        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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
        at $Proxy161.ruleCompliance(Unknown Source)
        at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)


    
> java.lang.RuntimeException: cannot invoke getter
> ------------------------------------------------
>
>                 Key: DROOLS-394
>                 URL: https://issues.jboss.org/browse/DROOLS-394
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>
> this is the log error:
> ----------------------------
> java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
>         at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
>         at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>         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:337)
>         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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
>         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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy161.ruleCompliance(Unknown Source)
>         at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)

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

From issues at jboss.org  Wed Jan  8 18:21:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Jan 2014 18:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.35669.1389223293253@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2729:
------------------------------

    Attachment: BdfHJ0fCUAAdRW5.png


Screenshot from tweet.
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Wed Jan  8 18:21:33 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jan 2014 18:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml with CDI entity listeners
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.35675.1389223293537@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2727:
------------------------------------

{quote}
Maybe I don't fully understand, but since Hibernate is used by WildFly and part of the JBoss community, what is stopping things from working out of the box now? Or is the extension you mention for a version of Hibernate newer than what WildFly is currently using?
{quote}
We did implement the 2-phase PU bootstrap in Hibernate (as an extension), however, we (Hibernate) still needs access to the datasource in the first phase.  With regard to DataSourceDefinition, I think it will help when HHH-8659 is addressed in Hibernate (to move datasource access to the second pu bootstrap phase).  

{quote}
Okay, so that's indeed more clear. But practically speaking there's also the issue now that users have to add the above mentioned property, isn't there? Since @DataSourceDefinition is largely an ease-of-use feature, this may be a bit problematic for exactly those users who are the intended target. If the issue can't be solved otherwise for the short term, would it be an option to provide a hint to the user when logging the error that this property needs to be set?
{quote}

I agree, that it is an issue that the user has to know to add the property.  In this case, the thrown error is generic and doesn't understand the context of what is causing the error.  It would be pretty cool if WildFly could determine that it is a datasource error and that the @DataSourceDefinition isn't available.  Even better, if a suggestion to address the failure (add a PU hint) could be given.

{quote}
This sounds like a very important improvement indeed and certainly worth it to create a JIRA issue on the JPA tracker for.
{quote}
Great idea!
                
> @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Wed Jan  8 18:21:33 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Wed, 8 Jan 2014 18:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001000.35678.1389223293687@jira02.app.mwc.hst.phx2.redhat.com>


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

leonardo lizana updated DROOLS-394:
-----------------------------------

    Description: 
we are using drools 5.4.final. 


this is the log error:
-------------------------
java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
        at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
        at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
        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:337)
        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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
        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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
        at $Proxy161.ruleCompliance(Unknown Source)
        at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)


  was:
this is the log error:
----------------------------

java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
        at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
        at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
        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:337)
        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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
        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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
        at $Proxy161.ruleCompliance(Unknown Source)
        at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)



    
> java.lang.RuntimeException: cannot invoke getter
> ------------------------------------------------
>
>                 Key: DROOLS-394
>                 URL: https://issues.jboss.org/browse/DROOLS-394
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>
> we are using drools 5.4.final. 
> this is the log error:
> -------------------------
> java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
>         at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
>         at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>         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:337)
>         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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
>         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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy161.ruleCompliance(Unknown Source)
>         at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)

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

From issues at jboss.org  Wed Jan  8 18:21:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Jan 2014 18:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.35683.1389223293921@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-2729:
---------------------------------

    Assignee: Max Rydahl Andersen  (was: Stuart Douglas)


Max can you take a look at this and help us understand what is going on.
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Max Rydahl Andersen
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Wed Jan  8 18:23:32 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Wed, 8 Jan 2014 18:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001000.35687.1389223412769@jira02.app.mwc.hst.phx2.redhat.com>


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

leonardo lizana updated DROOLS-394:
-----------------------------------

    Description: 
we are using drools 5.4.final. and below is the rule


rule "EnergyUsage data not empty"
      dialect "java"	
      salience 100
      no-loop
  when
      $httpResponse : HttpResponse(
									(((EnergyUsage)responseData).energyUsageDetail.billingGroup!=null && ((EnergyUsage)responseData).energyUsageDetail.billingGroup!=0) || 
      								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()>0 ||
									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()>0 ||
      								((EnergyUsage)responseData).energyUsageDetail.servicePoint!=null ||
      								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() > 0
      					);
      					
     
  then
      System.out.println("[EnergyUsage data not empty] rule has been fired...");
      $httpResponse.setStatusCode(EisConstants.STATUS_OK);
      $httpResponse.setErrorMessage("");
end

rule "EnergyUsage data empty"
      dialect "java"	
      no-loop
  when
      $httpResponse : HttpResponse(
									(((EnergyUsage)responseData).energyUsageDetail.billingGroup==null || ((EnergyUsage)responseData).energyUsageDetail.billingGroup==0) && 
      								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()==0 &&
									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()==0 &&
      								((EnergyUsage)responseData).energyUsageDetail.servicePoint==null &&
      								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() == 0
      					);
      					
     
  then
      System.out.println("[EnergyUsage data empty] rule has been fired...");
      $httpResponse.setStatusCode(EisConstants.STATUS_OK);
      $httpResponse.setErrorMessage("Data Screen Scrapping is empty for this account");
end

Here is log error:
-------------------------
java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
        at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
        at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
        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:337)
        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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
        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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
        at $Proxy161.ruleCompliance(Unknown Source)
        at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)


  was:
we are using drools 5.4.final. 


this is the log error:
-------------------------
java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
        at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
        at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
        at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
        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:337)
        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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
        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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
        at $Proxy161.ruleCompliance(Unknown Source)
        at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)



    
> java.lang.RuntimeException: cannot invoke getter
> ------------------------------------------------
>
>                 Key: DROOLS-394
>                 URL: https://issues.jboss.org/browse/DROOLS-394
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>
> we are using drools 5.4.final. and below is the rule
> rule "EnergyUsage data not empty"
>       dialect "java"	
>       salience 100
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup!=null && ((EnergyUsage)responseData).energyUsageDetail.billingGroup!=0) || 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()>0 ||
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()>0 ||
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint!=null ||
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() > 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data not empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("");
> end
> rule "EnergyUsage data empty"
>       dialect "java"	
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup==null || ((EnergyUsage)responseData).energyUsageDetail.billingGroup==0) && 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()==0 &&
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()==0 &&
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint==null &&
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() == 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("Data Screen Scrapping is empty for this account");
> end
> Here is log error:
> -------------------------
> java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
>         at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
>         at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>         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:337)
>         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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
>         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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy161.ruleCompliance(Unknown Source)
>         at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)

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

From issues at jboss.org  Wed Jan  8 18:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 18:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2658) (-Djboss.dist) jboss.dist
 property is not correctly propagated using -Djboss.dist
In-Reply-To: <JIRA.12528002.1387196044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528002.1387196044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528002.1387196044000.35699.1389225212953@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 970610|https://bugzilla.redhat.com/show_bug.cgi?id=970610] from POST to MODIFIED
                
> (-Djboss.dist) jboss.dist property is not correctly propagated using -Djboss.dist
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2658
>                 URL: https://issues.jboss.org/browse/WFLY-2658
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Zizka
>
> This JIRA is clone of bz-970610 (https://bugzilla.redhat.com/show_bug.cgi?id=970610)
> When I run testsuite of EAP 6.1.0 using command [1], where JBOSS_HOME is a path EAP 6.1.0, the manualmode tests fail with error [2]:
> It uses path defined in jboss.dist property defined in testsuite/integration/pom.xml instead of the one provided -Djboss.dist which should redefine it.
> [1] ./integration-tests.sh -Dpublic-repos -DallTests -Dmaven.repo.local=${MAVEN_REPO_LOCAL} -Djboss.dist=${JBOSS_HOME} -Dmaven.test.failure.ignore=true  -Dsurefire.forked.process.timeout=3600
> [2]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7-redhat-1:run (build-manual-mode-servers) on project jboss-as-ts-integ-manualmode: An Ant BuildException has occured: The following error occurred while executing this line:
> [ERROR] /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/src/test/scripts/manualmode-build.xml:52: /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/build/target/jboss-as-7.2.0.Final-redhat-8/modules does not exist.
> [ERROR] around Ant part ...<ant antfile="/mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/../src/test/scripts/manualmode-build.xml">... @ 4:180 in /mnt/hudson_workspace/workspace/eap-60-as-testsuite-one-offs-rhatlapa/jboss-eap-6.1-src/testsuite/integration/manualmode/target/antrun/build-main.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 issues at jboss.org  Wed Jan  8 18:57:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 18:57:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2668) Cannot execute "ssh
 $USER@$HOST service wildfly-init-redhat.sh restart" correctly in domain
 mode
In-Reply-To: <JIRA.12528195.1387412637000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528195.1387412637000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528195.1387412637000.35702.1389225452735@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1044461|https://bugzilla.redhat.com/show_bug.cgi?id=1044461] from POST to MODIFIED
                
> Cannot execute "ssh $USER@$HOST service wildfly-init-redhat.sh restart" correctly in domain mode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2668
>                 URL: https://issues.jboss.org/browse/WFLY-2668
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: RHEL 6
>            Reporter: Takayuki Konishi
>
> WildFly keep grabing a terminal after executing "ssh $USER@$HOST service wildfly-init-redhat.sh restart" in domain mode.
> How reproducible: 100%

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

From issues at jboss.org  Wed Jan  8 19:13:32 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:13:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Per-deployment descriptor
	replacement
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35705.1389226412812@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn commented on WFLY-2720:
-----------------------------------

Ah thanks for pointing me in the right direction.

While this makes it possible, I must also argue that overlaying files is not an optimal solution when I just want to overlay a variable.  An issue will occur if the xml files being replaced becomes modified but the patch xml does not get updated.


                
> Per-deployment descriptor replacement
> -------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently descriptor replacement (ie. in persistence.xml) is possible via system properties.  Unfortunately since system properties are global it is not possible to have per-deployment descriptor replacement.
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements.

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

From issues at jboss.org  Wed Jan  8 19:15:33 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:15:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Per-deployment descriptor
	replacement
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35708.1389226533680@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn reopened WFLY-2720:
-------------------------------


    
> Per-deployment descriptor replacement
> -------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently descriptor replacement (ie. in persistence.xml) is possible via system properties.  Unfortunately since system properties are global it is not possible to have per-deployment descriptor replacement.
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements.

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

From issues at jboss.org  Wed Jan  8 19:15:34 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35716.1389226534119@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn updated WFLY-2720:
------------------------------

    Summary: Ability for Deployment Overlays to overlay System Properties  (was: Per-deployment descriptor replacement)

    
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently descriptor replacement (ie. in persistence.xml) is possible via system properties.  Unfortunately since system properties are global it is not possible to have per-deployment descriptor replacement.
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements.

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

From issues at jboss.org  Wed Jan  8 19:19:32 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35723.1389226772816@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn updated WFLY-2720:
------------------------------

    Description: 
Currently Deployment Overlays allow for replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.

  was:
Currently descriptor replacement (ie. in persistence.xml) is possible via system properties.  Unfortunately since system properties are global it is not possible to have per-deployment descriptor replacement.

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements.


    
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently Deployment Overlays allow for replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System 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 issues at jboss.org  Wed Jan  8 19:21:33 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35726.1389226893070@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn updated WFLY-2720:
------------------------------

    Description: 
Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

ie.

    <deployment-overlays>
        <deployment-overlay name="myOverlay">
<system-properties>
        <property name="datasource.dockyard" value="java:jboss/datasources/dockyard"/>
    </system-properties>
            <content path="/WEB-INF/jboss-web.xml" content="/Users/josh/jboss-web.xml"/>
            <content path="/WEB-INF/classes/persistence.xml" content="/Users/josh/persistence.xml"/>
            <deployment name="controller2.war"/>
        </deployment-overlay>
    </deployment-overlays>

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.

  was:
Currently Deployment Overlays allow for replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.


    
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> ie.
>     <deployment-overlays>
>         <deployment-overlay name="myOverlay">
> <system-properties>
>         <property name="datasource.dockyard" value="java:jboss/datasources/dockyard"/>
>     </system-properties>
>             <content path="/WEB-INF/jboss-web.xml" content="/Users/josh/jboss-web.xml"/>
>             <content path="/WEB-INF/classes/persistence.xml" content="/Users/josh/persistence.xml"/>
>             <deployment name="controller2.war"/>
>         </deployment-overlay>
>     </deployment-overlays>
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System 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 issues at jboss.org  Wed Jan  8 19:23:32 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35731.1389227012846@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn updated WFLY-2720:
------------------------------

    Description: 
Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

ie.
{code:xml}
    <deployment-overlays>
        <deployment-overlay name="myOverlay">
<system-properties>
        <property name="datasource" value="java:jboss/datasources/controller"/>
    </system-properties>
            <deployment name="controller.war"/>
        </deployment-overlay>
    </deployment-overlays>
{code}

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.

  was:
Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

ie.

    <deployment-overlays>
        <deployment-overlay name="myOverlay">
<system-properties>
        <property name="datasource.dockyard" value="java:jboss/datasources/dockyard"/>
    </system-properties>
            <content path="/WEB-INF/jboss-web.xml" content="/Users/josh/jboss-web.xml"/>
            <content path="/WEB-INF/classes/persistence.xml" content="/Users/josh/persistence.xml"/>
            <deployment name="controller2.war"/>
        </deployment-overlay>
    </deployment-overlays>

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.


    
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> ie.
> {code:xml}
>     <deployment-overlays>
>         <deployment-overlay name="myOverlay">
> <system-properties>
>         <property name="datasource" value="java:jboss/datasources/controller"/>
>     </system-properties>
>             <deployment name="controller.war"/>
>         </deployment-overlay>
>     </deployment-overlays>
> {code}
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System 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 issues at jboss.org  Wed Jan  8 19:23:33 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35734.1389227013037@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn updated WFLY-2720:
------------------------------

    Description: 
Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

ie.
{code:xml}
    <deployment-overlays>
        <deployment-overlay name="myOverlay">
            <system-properties>
                <property name="datasource" value="java:jboss/datasources/controller"/>
            </system-properties>
            <deployment name="controller.war"/>
        </deployment-overlay>
    </deployment-overlays>
{code}

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.

  was:
Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.

ie.
{code:xml}
    <deployment-overlays>
        <deployment-overlay name="myOverlay">
<system-properties>
        <property name="datasource" value="java:jboss/datasources/controller"/>
    </system-properties>
            <deployment name="controller.war"/>
        </deployment-overlay>
    </deployment-overlays>
{code}

Usecase:
Have two deployments active of the same application, run-time configured by descriptor replacements via System Properties.


    
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> ie.
> {code:xml}
>     <deployment-overlays>
>         <deployment-overlay name="myOverlay">
>             <system-properties>
>                 <property name="datasource" value="java:jboss/datasources/controller"/>
>             </system-properties>
>             <deployment name="controller.war"/>
>         </deployment-overlay>
>     </deployment-overlays>
> {code}
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System 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 issues at jboss.org  Wed Jan  8 19:23:33 2014
From: issues at jboss.org (Joshua Henn (JIRA))
Date: Wed, 8 Jan 2014 19:23:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.35739.1389227013294@jira02.app.mwc.hst.phx2.redhat.com>


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

Joshua Henn edited comment on WFLY-2720 at 1/8/14 7:22 PM:
-----------------------------------------------------------

Ah thanks for pointing me in the right direction.

While this makes it possible, I must also argue that overlaying files is not an optimal solution when I just want to overlay a variable.  An issue will occur if the xml files being replaced becomes modified but the patch xml does not get updated.

Updated Feature Request.
                
      was (Author: smysnk):
    Ah thanks for pointing me in the right direction.

While this makes it possible, I must also argue that overlaying files is not an optimal solution when I just want to overlay a variable.  An issue will occur if the xml files being replaced becomes modified but the patch xml does not get updated.


                  
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> ie.
> {code:xml}
>     <deployment-overlays>
>         <deployment-overlay name="myOverlay">
>             <system-properties>
>                 <property name="datasource" value="java:jboss/datasources/controller"/>
>             </system-properties>
>             <deployment name="controller.war"/>
>         </deployment-overlay>
>     </deployment-overlays>
> {code}
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System 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 issues at jboss.org  Wed Jan  8 19:49:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 19:49:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.35767.1389228572699@jira02.app.mwc.hst.phx2.redhat.com>


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

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

James Perkins <jperkins at redhat.com> changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from NEW to POST
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {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 issues at jboss.org  Wed Jan  8 20:01:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 20:01:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.35797.1389229293171@jira02.app.mwc.hst.phx2.redhat.com>


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

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

James Perkins <jperkins at redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from NEW to POST
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {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 issues at jboss.org  Wed Jan  8 22:55:32 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 8 Jan 2014 22:55:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001000.35869.1389239732843@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-394:
---------------------------------------

Are you sure that responseData is 1) always not null and 2) always an instance of EnergyUsage?
You'll also have to make sure that none of the intermediate getters returns null.
                
> java.lang.RuntimeException: cannot invoke getter
> ------------------------------------------------
>
>                 Key: DROOLS-394
>                 URL: https://issues.jboss.org/browse/DROOLS-394
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>
> we are using drools 5.4.final. and below is the rule
> rule "EnergyUsage data not empty"
>       dialect "java"	
>       salience 100
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup!=null && ((EnergyUsage)responseData).energyUsageDetail.billingGroup!=0) || 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()>0 ||
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()>0 ||
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint!=null ||
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() > 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data not empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("");
> end
> rule "EnergyUsage data empty"
>       dialect "java"	
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup==null || ((EnergyUsage)responseData).energyUsageDetail.billingGroup==0) && 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()==0 &&
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()==0 &&
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint==null &&
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() == 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("Data Screen Scrapping is empty for this account");
> end
> Here is log error:
> -------------------------
> java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
>         at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
>         at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>         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:337)
>         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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
>         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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy161.ruleCompliance(Unknown Source)
>         at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)

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

From issues at jboss.org  Wed Jan  8 23:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 23:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.35874.1389241293038@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from NEW to POST
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Wed Jan  8 23:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 23:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.35878.1389241293221@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from NEW to POST
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

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

From issues at jboss.org  Wed Jan  8 23:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 23:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.35883.1389241293449@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from NEW to POST
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Wed Jan  8 23:21:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 23:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.35886.1389241293584@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from NEW to POST
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

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

From issues at jboss.org  Wed Jan  8 23:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 8 Jan 2014 23:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-89) LogContext's root logger is
 not created with a strong child hash map when strong=true
In-Reply-To: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525357.1384544962000.35892.1389243212977@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on LOGMGR-89:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1031221|https://bugzilla.redhat.com/show_bug.cgi?id=1031221] from NEW to MODIFIED
                
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-89
>                 URL: https://issues.jboss.org/browse/LOGMGR-89
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>             Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
>   <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <logger name="com.redhat" additivity="false">
>     <level value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP_MDB"/>
>   </logger>
>   <root>
>     <priority value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP"/>
>   </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used.  One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO  [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {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 issues at jboss.org  Thu Jan  9 05:29:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 05:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError:
 expected:<200> but was:<500>' in
 org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
In-Reply-To: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527235.1386342825000.36104.1389263372935@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1049796|https://bugzilla.redhat.com/show_bug.cgi?id=1049796] from NEW to POST
                
> Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2618
>                 URL: https://issues.jboss.org/browse/WFLY-2618
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-3843551226685549253&tab=testDetails
> The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s.

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

From issues at jboss.org  Thu Jan  9 06:13:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528945.1389266004860@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528945.1389266004860@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528945.1389266004860.36155.1389266013069@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1767:
------------------------------

             Summary: UNICAST3: processing of OOB messages and message batches
                 Key: JGRP-1767
                 URL: https://issues.jboss.org/browse/JGRP-1767
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


Currently, when OOB message batches are received, the following happens:
* All messages from the batch are added to the table
* We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
* The batch is passed up
* Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
** Messages whose {{OOB_DELIVERED}} flag is set, are discarded

This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
* The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
** Batch
*** we only add those messages from list L to table T if they haven't yet been added
*** Messages from L which couldn't be added to T are removed from L
*** All messages from L are added to a new batch and that batch is then passed up (delivered)
** Single message
*** If the message was added successfuly, we deliver it, else we drop it
* When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
* Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages

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

From issues at jboss.org  Thu Jan  9 06:15:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:15:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528945.1389266004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528945.1389266004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528945.1389266004000.36158.1389266133929@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1767:
--------------------------------

In a nutshell, for OOB messages, we only use Table as a means to keep track of which seqnos have been delivered, to prevent duplicate delivery. We're not interested in the messages themselves, as they've been delivered by the processing thread from the OOB thread pool.
                
> UNICAST3: processing of OOB messages and message batches
> --------------------------------------------------------
>
>                 Key: JGRP-1767
>                 URL: https://issues.jboss.org/browse/JGRP-1767
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Currently, when OOB message batches are received, the following happens:
> * All messages from the batch are added to the table
> * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
> * The batch is passed up
> * Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
> ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
> This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
> * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
> ** Batch
> *** we only add those messages from list L to table T if they haven't yet been added
> *** Messages from L which couldn't be added to T are removed from L
> *** All messages from L are added to a new batch and that batch is then passed up (delivered)
> ** Single message
> *** If the message was added successfuly, we deliver it, else we drop it
> * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
> * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages

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

From issues at jboss.org  Thu Jan  9 06:17:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528945.1389266004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528945.1389266004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528945.1389266004000.36161.1389266252807@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1767 at 1/9/14 6:15 AM:
--------------------------------------------------------

In other words, for OOB messages, we only use Table as a means to keep track of which seqnos have been delivered, to prevent duplicate delivery. We're not interested in the messages themselves, as they've been delivered by the processing thread from the OOB thread pool.
                
      was (Author: belaban):
    In a nutshell, for OOB messages, we only use Table as a means to keep track of which seqnos have been delivered, to prevent duplicate delivery. We're not interested in the messages themselves, as they've been delivered by the processing thread from the OOB thread pool.
                  
> UNICAST3: processing of OOB messages and message batches
> --------------------------------------------------------
>
>                 Key: JGRP-1767
>                 URL: https://issues.jboss.org/browse/JGRP-1767
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Currently, when OOB message batches are received, the following happens:
> * All messages from the batch are added to the table
> * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
> * The batch is passed up
> * Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
> ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
> This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
> * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
> ** Batch
> *** we only add those messages from list L to table T if they haven't yet been added
> *** Messages from L which couldn't be added to T are removed from L
> *** All messages from L are added to a new batch and that batch is then passed up (delivered)
> ** Single message
> *** If the message was added successfuly, we deliver it, else we drop it
> * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
> * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages

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

From issues at jboss.org  Thu Jan  9 06:17:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1768) NAKACK2: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528948.1389266207026@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528948.1389266207026@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528948.1389266207026.36173.1389266253371@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1768:
------------------------------

             Summary: NAKACK2: processing of OOB messages and message batches
                 Key: JGRP-1768
                 URL: https://issues.jboss.org/browse/JGRP-1768
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


Currently, when OOB message batches are received, the following happens:
* All messages from the batch are added to the table
* We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
* The batch is passed up
* Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
** Messages whose {{OOB_DELIVERED}} flag is set, are discarded

This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
* The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
** Batch
*** we only add those messages from list L to table T if they haven't yet been added
*** Messages from L which couldn't be added to T are removed from L
*** All messages from L are added to a new batch and that batch is then passed up (delivered)
** Single message
*** If the message was added successfuly, we deliver it, else we drop it
* When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
* Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages

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

From issues at jboss.org  Thu Jan  9 06:19:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1768) NAKACK2: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528948.1389266207000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528948.1389266207000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528948.1389266207000.36176.1389266372846@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1768:
---------------------------

    Description: See if the ideas detailed in JGRP-1767 can be applied to NAKACK2  (was: Currently, when OOB message batches are received, the following happens:
* All messages from the batch are added to the table
* We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
* The batch is passed up
* Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
** Messages whose {{OOB_DELIVERED}} flag is set, are discarded

This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
* The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
** Batch
*** we only add those messages from list L to table T if they haven't yet been added
*** Messages from L which couldn't be added to T are removed from L
*** All messages from L are added to a new batch and that batch is then passed up (delivered)
** Single message
*** If the message was added successfuly, we deliver it, else we drop it
* When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
* Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages)

    
> NAKACK2: processing of OOB messages and message batches
> -------------------------------------------------------
>
>                 Key: JGRP-1768
>                 URL: https://issues.jboss.org/browse/JGRP-1768
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> See if the ideas detailed in JGRP-1767 can be applied to NAKACK2

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

From issues at jboss.org  Thu Jan  9 06:19:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1768) NAKACK2: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528948.1389266207000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528948.1389266207000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528948.1389266207000.36179.1389266373018@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1768:
---------------------------

    Description: See if the ideas discussed in JGRP-1767 can be applied to NAKACK2  (was: See if the ideas detailed in JGRP-1767 can be applied to NAKACK2)

    
> NAKACK2: processing of OOB messages and message batches
> -------------------------------------------------------
>
>                 Key: JGRP-1768
>                 URL: https://issues.jboss.org/browse/JGRP-1768
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> See if the ideas discussed in JGRP-1767 can be applied to NAKACK2

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

From issues at jboss.org  Thu Jan  9 06:45:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 06:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1769) Table.add() with message list
 can lead to many resizings
In-Reply-To: <JIRA.12528968.1389267831742@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528968.1389267831742@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528968.1389267831742.36256.1389267933719@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1769:
------------------------------

             Summary: Table.add() with message list can lead to many resizings
                 Key: JGRP-1769
                 URL: https://issues.jboss.org/browse/JGRP-1769
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.5


Table maintains an array of arrays (a matrix) and needs to resize it when adding messages that would go beyond the capacity of the array.
This is done when adding a message.
However, when adding a *list of messages*, as we're adding messages individually, we compute the needed capacity and perform a resize if needed.
This leads to possibly too much copying.
SOLUTION:
* When adding a list of messages, do the resizing (if needed) *before* adding messages individually

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

From issues at jboss.org  Thu Jan  9 06:45:34 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 9 Jan 2014 06:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2523) cygwin jboss-cli.sh
In-Reply-To: <JIRA.12525383.1384716417000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525383.1384716417000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525383.1384716417000.36261.1389267934003@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved WFLY-2523.
-------------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done


Merged into master.
                
> cygwin jboss-cli.sh
> -------------------
>
>                 Key: WFLY-2523
>                 URL: https://issues.jboss.org/browse/WFLY-2523
>             Project: WildFly
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>         Environment: windows 7 x64 / cygwin
>            Reporter: Darko Palic
>            Assignee: Alexey Loubyansky
>              Labels: cli, cygwin
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> On cygwin is the implementation of the path variables not correct in the script jboss-cli.sh. Right now under cygwin the paths get mixed in POSIX and Windows style. The module path (-mp param) is in POSIX style and the rest of the command is in windows style. So the startup of the org.jboss.as.cli ends up with
> {code}
> org.jboss.modules.ModuleNotFoundException: org.jboss.as.cli:main
>         at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
>         at org.jboss.modules.Main.main(Main.java:385)
> {code}
> Right now wildfly 8 beta1 has following implementation:
> {code:title=jboss-cli.sh|borderStyle=solid}
> # For Cygwin, switch paths to Windows format before running java
> if $cygwin; then
>     JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
>     JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
> fi
> {code}
> and it should be:
> {code:title=jboss-cli.sh|borderStyle=solid}
> # For Cygwin, switch paths to Windows format before running java
> if $cygwin; then
>     JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
>     JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
>     JBOSS_MODULEPATH=`cygpath --path --windows "$JBOSS_MODULEPATH"`
> fi
> {code}
> PS: I searched for similar cli issues in the issue tracker, but couldn't find any 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 issues at jboss.org  Thu Jan  9 06:59:32 2014
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Thu, 9 Jan 2014 06:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-395) If a change set has a
 resource pointing to Guvnor, the resource is rejected because of http 401
In-Reply-To: <JIRA.12528969.1389268753926@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528969.1389268753926@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528969.1389268753926.36300.1389268772804@jira02.app.mwc.hst.phx2.redhat.com>

Toni Rikkola created DROOLS-395:
-----------------------------------

             Summary: If a change set has a resource pointing to Guvnor, the resource is rejected because of http 401
                 Key: DROOLS-395
                 URL: https://issues.jboss.org/browse/DROOLS-395
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Toni Rikkola
            Assignee: Toni Rikkola




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

From issues at jboss.org  Thu Jan  9 07:01:33 2014
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Thu, 9 Jan 2014 07:01:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-395) If a change set has a
 resource pointing to Guvnor, the resource is rejected because of http 401
In-Reply-To: <JIRA.12528969.1389268753000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528969.1389268753000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528969.1389268753000.36302.1389268893611@jira02.app.mwc.hst.phx2.redhat.com>


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

Toni Rikkola resolved DROOLS-395.
---------------------------------

    Resolution: Done

    
> If a change set has a resource pointing to Guvnor, the resource is rejected because of http 401
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-395
>                 URL: https://issues.jboss.org/browse/DROOLS-395
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>


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

From issues at jboss.org  Thu Jan  9 07:25:32 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 9 Jan 2014 07:25:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-379) Dispose KnowledgeBases
In-Reply-To: <JIRA.12527978.1387091537000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527978.1387091537000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527978.1387091537000.36360.1389270332951@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco reassigned DROOLS-379:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Dispose KnowledgeBases
> ----------------------
>
>                 Key: DROOLS-379
>                 URL: https://issues.jboss.org/browse/DROOLS-379
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> Release the resources held by a KnowledgeBase
> - Package ClassLoaders and their loaded classes
> - Dialect Registries
> - Listeners
> ...

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

From issues at jboss.org  Thu Jan  9 07:25:33 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 9 Jan 2014 07:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-379) Dispose KnowledgeBases
In-Reply-To: <JIRA.12527978.1387091537000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527978.1387091537000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527978.1387091537000.36366.1389270333269@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco resolved DROOLS-379.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.1.Final
       Resolution: Done

    
> Dispose KnowledgeBases
> ----------------------
>
>                 Key: DROOLS-379
>                 URL: https://issues.jboss.org/browse/DROOLS-379
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.1.Final
>
>
> Release the resources held by a KnowledgeBase
> - Package ClassLoaders and their loaded classes
> - Dialect Registries
> - Listeners
> ...

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

From issues at jboss.org  Thu Jan  9 07:37:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 07:37:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.36391.1389271052870@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1717:
---------------------------

    Attachment: fast.xml


The attached fast.xml file has an OOB thread pool queue *enabled*. This is important for performance if we send a lot of OOB messages
                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Thu Jan  9 07:39:32 2014
From: issues at jboss.org (David Richmond (JIRA))
Date: Thu, 9 Jan 2014 07:39:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.36400.1389271172853@jira02.app.mwc.hst.phx2.redhat.com>


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

David Richmond commented on WFLY-2265:
--------------------------------------

Causes ZK framework (v6.5) to fail to load its localised messages - http://www.zkoss.org/

ZK has previously worked fine in all its versions on all versions of JBoss since v4.2

13:05:31,413 INFO  [org.zkoss] (default task-8) Loading labels for en_GB
13:05:31,413 SEVERE [org.zkoss] (default task-8) >>java.lang.NullPointerException
>>	at io.undertow.servlet.spec.ServletContextImpl.getResource(ServletContextImpl.java:223)
>>	at org.zkoss.web.util.resource.ServletLabelLocator.locate0(ServletLabelLocator.java:88)
>>	at org.zkoss.web.util.resource.ServletLabelLocator.locate(ServletLabelLocator.java:73)
>>	at org.zkoss.util.resource.impl.LabelLoader.loadLabels(LabelLoader.java:253)
>>	at org.zkoss.util.resource.impl.LabelLoader.getLabel(LabelLoader.java:111)
>>	at org.zkoss.util.resource.impl.LabelLoader.getLabel(LabelLoader.java:102)
>>	at org.zkoss.util.resource.Labels.getLabel(Labels.java:44)
>>	at org.zkoss.mesg.Messages.getFromBundle(Messages.java:80)
>>	at org.zkoss.mesg.Messages.get(Messages.java:133)
>>	at org.zkoss.mesg.Messages.get(Messages.java:51)
>>	at org.zkoss.zul.impl.Utils.addLocaleJS(Utils.java:253)
>>	at org.zkoss.zul.impl.Utils.outLocaleJavaScript(Utils.java:243)

                
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Tomaz Cerar
>              Labels: jboss
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

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

From issues at jboss.org  Thu Jan  9 07:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 07:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.36428.1389272012851@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1047536|https://bugzilla.redhat.com/show_bug.cgi?id=1047536] from POST to MODIFIED
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Thu Jan  9 07:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 07:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError:
 expected:<200> but was:<500>' in
 org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
In-Reply-To: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527235.1386342825000.36431.1389272013047@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1049796|https://bugzilla.redhat.com/show_bug.cgi?id=1049796] from POST to MODIFIED
                
> Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2618
>                 URL: https://issues.jboss.org/browse/WFLY-2618
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-3843551226685549253&tab=testDetails
> The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s.

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

From issues at jboss.org  Thu Jan  9 07:53:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 07:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2514) Using directory grouping
 by-type results in the wrong logging.properties file being used
In-Reply-To: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525194.1384479524000.36433.1389272013152@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1050068|https://bugzilla.redhat.com/show_bug.cgi?id=1050068] from ASSIGNED to MODIFIED
                
> Using directory grouping by-type results in the wrong logging.properties file being used
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2514
>                 URL: https://issues.jboss.org/browse/WFLY-2514
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> When defining servers with {{directory-grouping="by-type"}} the wrong directory is used in the {{ManagedServerBootCmdFactory}}. This causes the {{domain/configuration/logging.properties}} to always be used which is the incorrect configuration to use.

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

From issues at jboss.org  Thu Jan  9 08:27:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 08:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.36496.1389274053283@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1717:
--------------------------------

Tested perf with UPerf (measures throughput and latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT (A) || SSWT (B) || SSWT (C) || TQ (A) || TQ (B) || TQ (C) || SS (A) || SS (B) || SS (C) ||
|   1 | 4754 | 4545 | 23 | 4809 | 4415 | 4647 | 4698 | 4718 | 4656 |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | 14079 | 15715 | 14275 | 13782 |
| 10 | 22948 | 21192 | 227 | 23232 | 22576 | 22312 | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | 29282 | 25522 | 25673 | 28228 | 20890 |

                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Thu Jan  9 08:59:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 08:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.36538.1389275973112@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/9/14 8:57 AM:
--------------------------------------------------------

Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT (A) || SSWT (B) || SSWT (C) || TQ (A) || TQ (B) || TQ (C) || SS (A) || SS (B) || SS (C) ||
|   1 | 4754 | 4545 | 23 | 4809 | 4415 | 4647 | 4698 | 4718 | 4656 |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | 14079 | 15715 | 14275 | 13782 |
| 10 | 22948 | 21192 | 227 | 23232 | 22576 | 22312 | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | 29282 | 25522 | 25673 | 28228 | 20890 |

                
      was (Author: belaban):
    Tested perf with UPerf (measures throughput and latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT (A) || SSWT (B) || SSWT (C) || TQ (A) || TQ (B) || TQ (C) || SS (A) || SS (B) || SS (C) ||
|   1 | 4754 | 4545 | 23 | 4809 | 4415 | 4647 | 4698 | 4718 | 4656 |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | 14079 | 15715 | 14275 | 13782 |
| 10 | 22948 | 21192 | 227 | 23232 | 22576 | 22312 | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | 29282 | 25522 | 25673 | 28228 | 20890 |

                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Thu Jan  9 09:09:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 09:09:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.36556.1389276573376@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/9/14 9:09 AM:
--------------------------------------------------------

Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C ||
|   1 | 4754 | 4545 | 23 | 4809 | 4415 | 4647 | 4698 | 4718 | 4656 |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | 14079 | 15715 | 14275 | 13782 |
| 10 | 22948 | 21192 | 227 | 23232 | 22576 | 22312 | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | 29282 | 25522 | 25673 | 28228 | 20890 |

Comments:
* SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler
* SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency
** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense
* With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan).
** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed
* Infinispan uses option B when invoking sync RPCs
                
      was (Author: belaban):
    Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT (A) || SSWT (B) || SSWT (C) || TQ (A) || TQ (B) || TQ (C) || SS (A) || SS (B) || SS (C) ||
|   1 | 4754 | 4545 | 23 | 4809 | 4415 | 4647 | 4698 | 4718 | 4656 |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | 14079 | 15715 | 14275 | 13782 |
| 10 | 22948 | 21192 | 227 | 23232 | 22576 | 22312 | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | 29282 | 25522 | 25673 | 28228 | 20890 |

                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Thu Jan  9 09:13:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 09:13:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.36563.1389276812802@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/9/14 9:13 AM:
--------------------------------------------------------

Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C ||
|   1 | 4754 | 4545 | 23 | *4809* | 4415 | 4647 | 4698 | *4718* | *4656* |
|   4 | 14699 | 14033 | 74 | *15122* | 13864 | *14079* | 15715 | *14275* | 13782 |
| 10 | 22948 | 21192 | 227 | *23232* | *22576* | *22312* | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | *29282* | *25522* | *25673* | 28228 | 20890 |

Comments:
* SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler
* SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency
** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense
* With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan).
** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed
* Infinispan uses option B when invoking sync RPCs
                
      was (Author: belaban):
    Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C ||
|   1 | 4754 | 4545 | 23 | 4809 | 4415 | 4647 | 4698 | 4718 | 4656 |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | 14079 | 15715 | 14275 | 13782 |
| 10 | 22948 | 21192 | 227 | 23232 | 22576 | 22312 | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | 29282 | 25522 | 25673 | 28228 | 20890 |

Comments:
* SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler
* SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency
** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense
* With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan).
** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed
* Infinispan uses option B when invoking sync RPCs
                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Thu Jan  9 09:15:34 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jan 2014 09:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.36569.1389276934714@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1717 at 1/9/14 9:13 AM:
--------------------------------------------------------

Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C ||
|   1 | 4754 | 4545 | 23 | *4809* | 4415 | 4647 | 4698 | *4718* | *4656* |
|   4 | 14699 | 14033 | 74 | 15122 | 13864 | *14079* | *15715* | *14275* | 13782 |
| 10 | 22948 | 21192 | 227 | *23232* | *22576* | *22312* | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | *29282* | *25522* | *25673* | 28228 | 20890 |

Comments:
* SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler
* SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency
** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense
* With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan).
** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed
* Infinispan uses option B when invoking sync RPCs
                
      was (Author: belaban):
    Tested perf with UPerf (measures throughput and latency)
Environment:
- JGroups master (3.5) with JGRP-1767 and JGRP-1768 included
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 8 nodes: cluster01-08
- fast.xml (attached) with ip_ttl=1 *and queue for OOB thread pool*
- Each node invokes 20'000 RPCs: 80% sync GETs and 20% async PUTs
- numOwners=2

- Configs are:
|| A || B || C ||
| ignore_dont_bundle=false | ignore_dont_bundle=true | ignore_dont_bundle=true|
| {{+DONT_BUNDLE +OOB}} | {{+DONT_BUNDLE +OOB}} | {{-DONT_BUNDLE -OOB}} |



The results are (in avg. requests / sec / node):

|| Invoker threads || SSWT-A || SSWT-B || SSWT-C || TQ-A || TQ-B || TQ-C || SS-A || SS-B || SS-C ||
|   1 | 4754 | 4545 | 23 | *4809* | 4415 | 4647 | 4698 | *4718* | *4656* |
|   4 | 14699 | 14033 | 74 | *15122* | 13864 | *14079* | 15715 | *14275* | 13782 |
| 10 | 22948 | 21192 | 227 | *23232* | *22576* | *22312* | 22487 | 21920 | 18403 |
| 20 | 24431 | 23738 | 340 | 23988 | *29282* | *25522* | *25673* | 28228 | 20890 |

Comments:
* SSWT-B: messages are not bundled (even though ignore_don_bundle=true) as the code has an exception for this bundler
* SSWT-C: this bundler has a max_bundle_time of 30ms, so each request and response can have up to 30ms added to it, which is very bad for latency
** Running sync RPCs on SSWT without {{+DONT_BUNDLE | +OOB}} doesn't make any sense
* With option C, the cost of batching doesn't really show (although it *is* a bit slower than option B), as UPerf doesn't do anything real (unlike Infinispan).
** However, the slower perf of C against B is caused by all requests in a batch being processed *sequentially* and therefore responses sent before the next request is processed slow down overall speed
* Infinispan uses option B when invoking sync RPCs
                  
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Thu Jan  9 09:27:32 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 9 Jan 2014 09:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.36635.1389277652927@jira02.app.mwc.hst.phx2.redhat.com>


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

Matteo Mortari commented on DROOLS-373:
---------------------------------------

I'm appending a comment here, to see if it would trigger revaluation of the status of this bug to reopened, because from my test it does not resolve and I will explain why further down below.
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Thu Jan  9 09:43:32 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 9 Jan 2014 09:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.36717.1389278612919@jira02.app.mwc.hst.phx2.redhat.com>


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

Matteo Mortari updated DROOLS-373:
----------------------------------

    Attachment: drools6scratch-kiemavenclasspath.zip


I've made a quick example project, to prove the point, but from my side this still does not work. 

The project is a KIE project, and has a dependency, enlisted in maven pom as:
{code:xml}
	<dependency>
		<groupId>org.apache.commons</groupId>
		<artifactId>commons-lang3</artifactId>
		<version>3.1</version>
	</dependency>
{code}

Then there is a very simple DRL file, for very dummy rules:
{code:title=package.drl}
package com.acme.drools6scratch_kiemavenclasspath

global org.apache.commons.lang3.tuple.ImmutablePair ip;

import org.apache.commons.lang3.tuple.* ;

rule "prova"
when
	$ip : ImmutablePair()
then
	System.out.println("detected");
end
{code}

Now.
If you run maven lifecycle with the pom in the current state, it will fail with:
{noformat}
[INFO] --- kie-maven-plugin:6.0.1.Final:build (default-build) @ drools6scratch-kiemavenclasspath ---
java.lang.ClassNotFoundException: Unable to find class 'org.apache.commons.lang3.tuple.ImmutablePair'
{noformat}

Actually, if you enlist the 'commons-lang3' dependency ALSO inside the kie-maven-plugin by removing the commented part in the pom, then kie-maven-plugin will be able to compile without the error above.

I think this issue was meant to avoid exactly this situation which happened in 6.0.0 ? 

I'm using 6.0.1.Final.

Maybe I'm doing something wrong from my side, but could you kindly evaluate if actually necessary to put this issue in status reopened, please?

Thanks, Ciao!
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools6scratch-kiemavenclasspath.zip
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Thu Jan  9 09:49:32 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 9 Jan 2014 09:49:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2730) HTTP upgrade does not accept
 multiple acceptors
In-Reply-To: <JIRA.12528997.1389278853581@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528997.1389278853581@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528997.1389278853581.36728.1389278972838@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2730:
---------------------------------

             Summary: HTTP upgrade does not accept multiple acceptors
                 Key: WFLY-2730
                 URL: https://issues.jboss.org/browse/WFLY-2730
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.Final


The http-acceptors are multiplexed over the HTTP port.
If there are multiple http-acceptors registered, a http-connector that uses the HTTP upgrade mechanism will use the first whose handshake is successful and can not chose a given http-acceptor.
With native messaging ports, the solution was to use different ports for different acceptors but with HTTP upgrade, everything goes through the HTTP port.

HornetQ connectors must pass "http-upgrade-endpoint" when the HTTP upgrade is initiated so that we ensure the handshake is successful only for the matching acceptor corresponding to the "http-upgrade-endpoint" 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 issues at jboss.org  Thu Jan  9 09:49:33 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 9 Jan 2014 09:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2731) HTTP upgrade does not accept
 multiple acceptors
In-Reply-To: <JIRA.12528998.1389278873828@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528998.1389278873828@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528998.1389278873828.36733.1389278973200@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2731:
---------------------------------

             Summary: HTTP upgrade does not accept multiple acceptors
                 Key: WFLY-2731
                 URL: https://issues.jboss.org/browse/WFLY-2731
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.Final


The http-acceptors are multiplexed over the HTTP port.
If there are multiple http-acceptors registered, a http-connector that uses the HTTP upgrade mechanism will use the first whose handshake is successful and can not chose a given http-acceptor.
With native messaging ports, the solution was to use different ports for different acceptors but with HTTP upgrade, everything goes through the HTTP port.

HornetQ connectors must pass "http-upgrade-endpoint" when the HTTP upgrade is initiated so that we ensure the handshake is successful only for the matching acceptor corresponding to the "http-upgrade-endpoint" 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 issues at jboss.org  Thu Jan  9 10:27:33 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Thu, 9 Jan 2014 10:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.36788.1389281253732@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Hasse commented on AS7-1389:
----------------------------------

The decision to include visibility to specific third party logging implementations by default seems absolutely against the basic philosophy of modules in a JEE container environment.  This sort of logging is simply not a JEE container feature and default visibility should not be provided and the debate should end there.  Those wanting to use the vendor-specific non-spec container facility should be the ones configuring an explicit dependency.

I find David Lloyd's anecdotal observations on which this decision was based to be simply not accurate in my large enterprise experience where you want to decouple the application from the container excepting for the specified JEE facilities.  If someone thinks otherwise I'm certainly interested to understand why.

Especially justifying the decision based on portability seems exactly backwards.  JBoss is going beyond the specification to provide a vendor-specific facility that in fact reduces portability.

Please consider re-thinking this decision moving forward.

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 10:35:35 2014
From: issues at jboss.org (Mustafa Musaji (JIRA))
Date: Thu, 9 Jan 2014 10:35:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to
 MDB @PreDestroy methods
In-Reply-To: <JIRA.12529009.1389281709801@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529009.1389281709801@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529009.1389281709801.36810.1389281735835@jira02.app.mwc.hst.phx2.redhat.com>

Mustafa Musaji created WFLY-2732:
------------------------------------

             Summary: Injected EJB not available to MDB @PreDestroy methods
                 Key: WFLY-2732
                 URL: https://issues.jboss.org/browse/WFLY-2732
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
    Affects Versions: 8.0.0.CR1
            Reporter: Mustafa Musaji
            Assignee: Stuart Douglas


MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed.

This was fixed in an RFE for Session Beans but does not seem to work 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 issues at jboss.org  Thu Jan  9 10:37:33 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Thu, 9 Jan 2014 10:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-263) JASPI Support for Web Services
In-Reply-To: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457542.1327505819000.36818.1389281853310@jira02.app.mwc.hst.phx2.redhat.com>


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

Alessio Soldano updated WFLY-263:
---------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)
                       (was: 8.0.0.Final)

    
> JASPI Support for Web Services
> ------------------------------
>
>                 Key: WFLY-263
>                 URL: https://issues.jboss.org/browse/WFLY-263
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web Services
>            Reporter: Anil Saldhana
>            Assignee: Jim Ma
>             Fix For: 9.0.0.CR1
>
>
> Take care of the JASPI requirements for SOAP layer.

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

From issues at jboss.org  Thu Jan  9 10:37:33 2014
From: issues at jboss.org (Mustafa Musaji (JIRA))
Date: Thu, 9 Jan 2014 10:37:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to
 MDB @PreDestroy methods
In-Reply-To: <JIRA.12529009.1389281709000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529009.1389281709000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529009.1389281709000.36820.1389281853416@jira02.app.mwc.hst.phx2.redhat.com>


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

Mustafa Musaji updated WFLY-2732:
---------------------------------

    Attachment: MDBLifeCycleJAR.zip


Attached reproducer with client. You will need to add 

{code}
                    <jms-queue name="TestQueue">
                        <entry name="java:jboss/exported/jms/TestQueue"/>
                        <entry name="jms/TestQueue"/>
                        <durable>true</durable>
                    </jms-queue>
{code}

to your standalone-full.xml and a application user "guest" using the password in the client code.
                
> Injected EJB not available to MDB @PreDestroy methods
> -----------------------------------------------------
>
>                 Key: WFLY-2732
>                 URL: https://issues.jboss.org/browse/WFLY-2732
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Mustafa Musaji
>            Assignee: Stuart Douglas
>         Attachments: MDBLifeCycleJAR.zip
>
>
> MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed.
> This was fixed in an RFE for Session Beans but does not seem to work 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 issues at jboss.org  Thu Jan  9 11:01:34 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 9 Jan 2014 11:01:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink subsystems
In-Reply-To: <JIRA.12529014.1389283289364@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289364@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289364.36873.1389283294651@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2733:
--------------------------------

             Summary: Create PicketLink subsystems
                 Key: WFLY-2733
                 URL: https://issues.jboss.org/browse/WFLY-2733
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
             Fix For: 8.0.0.Final


At a minimum IDM and Federation

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

From issues at jboss.org  Thu Jan  9 11:09:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 9 Jan 2014 11:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.36918.1389283772760@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated WFLY-2733:
-----------------------------

    Summary: Create PicketLink extension and subsystems  (was: Create PicketLink subsystems)

    
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> At a minimum IDM and Federation

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

From issues at jboss.org  Thu Jan  9 11:11:33 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 9 Jan 2014 11:11:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-783) LdapExtLoginModule's
 bindCredential requires vault string to be in a slightly different format
 than other components
In-Reply-To: <JIRA.12529018.1389283872460@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529018.1389283872460@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529018.1389283872460.36931.1389283893374@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created SECURITY-783:
-------------------------------------

             Summary: LdapExtLoginModule's bindCredential requires vault string to be in a slightly different format than other components
                 Key: SECURITY-783
                 URL: https://issues.jboss.org/browse/SECURITY-783
             Project: PicketBox 
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PicketBox
    Affects Versions: PicketBox_4_0_19.Final
            Reporter: Derek Horton
            Assignee: Stefan Guilhen
            Priority: Minor


The LdapExtLoginModule requires that the vault string used for the bindCredentials not include the '${' prefix and '}' suffix.  This is different than other places in the standalone.xml file where the ${ and } are 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 issues at jboss.org  Thu Jan  9 11:13:34 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 9 Jan 2014 11:13:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-783) LdapExtLoginModule's
 bindCredential requires vault string to be in a slightly different format
 than other components
In-Reply-To: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529018.1389283872000.36947.1389284014316@jira02.app.mwc.hst.phx2.redhat.com>


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

Derek Horton updated SECURITY-783:
----------------------------------

    Attachment: SECURITY-783.patch

    
> LdapExtLoginModule's bindCredential requires vault string to be in a slightly different format than other components
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-783
>                 URL: https://issues.jboss.org/browse/SECURITY-783
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>            Priority: Minor
>         Attachments: SECURITY-783.patch
>
>
> The LdapExtLoginModule requires that the vault string used for the bindCredentials not include the '${' prefix and '}' suffix.  This is different than other places in the standalone.xml file where the ${ and } are 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 issues at jboss.org  Thu Jan  9 11:13:34 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 9 Jan 2014 11:13:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-783) LdapExtLoginModule's
 bindCredential requires vault string to be in a slightly different format
 than other components
In-Reply-To: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529018.1389283872000.36951.1389284014486@jira02.app.mwc.hst.phx2.redhat.com>


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

Derek Horton commented on SECURITY-783:
---------------------------------------

I've attached a potential patch to resolve this issue.
                
> LdapExtLoginModule's bindCredential requires vault string to be in a slightly different format than other components
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-783
>                 URL: https://issues.jboss.org/browse/SECURITY-783
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>            Priority: Minor
>         Attachments: SECURITY-783.patch
>
>
> The LdapExtLoginModule requires that the vault string used for the bindCredentials not include the '${' prefix and '}' suffix.  This is different than other places in the standalone.xml file where the ${ and } are 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 issues at jboss.org  Thu Jan  9 11:17:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 11:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-783) LdapExtLoginModule's
 bindCredential requires vault string to be in a slightly different format
 than other components
In-Reply-To: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529018.1389283872000.36959.1389284253027@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated SECURITY-783:
---------------------------------------------

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

    
> LdapExtLoginModule's bindCredential requires vault string to be in a slightly different format than other components
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-783
>                 URL: https://issues.jboss.org/browse/SECURITY-783
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>            Priority: Minor
>         Attachments: SECURITY-783.patch
>
>
> The LdapExtLoginModule requires that the vault string used for the bindCredentials not include the '${' prefix and '}' suffix.  This is different than other places in the standalone.xml file where the ${ and } are 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 issues at jboss.org  Thu Jan  9 11:21:32 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 9 Jan 2014 11:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.36969.1389284492911@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1389:
----------------------------------

JBoss AS and its successor, WildFly, are not Java EE containers, they are containers that happen to support Java EE (and have in the past and will in the future support other things as well, as the industry changes).  Given this, and that philosophy is subjective by definition, and community feedback over the years, I stand by this decision; I am sorry it does not hold up for your specific environment though.  To this end, there is another open task right now to add a management attribute which disables this behavior in the logging subsystem.  Since changing it will then be a simple matter, I think that would resolve this issue.
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 11:31:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 11:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2484) Revise clustering tests
In-Reply-To: <JIRA.12524748.1384164224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524748.1384164224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524748.1384164224000.37019.1389285092753@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar reassigned WFLY-2484:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)

    
> Revise clustering tests
> -----------------------
>
>                 Key: WFLY-2484
>                 URL: https://issues.jboss.org/browse/WFLY-2484
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> Paul pointed out that some of the tests are no longer relevant with the new implementation and some were never actually relevant, e.g. duplicate tests.
> We should revise the set of tests to keep the testsuite small and find out missing 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 issues at jboss.org  Thu Jan  9 12:03:32 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 9 Jan 2014 12:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1132) Fix NPE of
 reauthenticationSupport in OutboundResourceAdapterImpl
In-Reply-To: <JIRA.12528629.1388981720000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528629.1388981720000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528629.1388981720000.37084.1389287012940@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated JBJCA-1132:
-----------------------------------

              Summary: Fix NPE of reauthenticationSupport in OutboundResourceAdapterImpl  (was: fix NPE of reauthenticationSupport in OutboundResourceAdapterImpl)
             Assignee: Jesper Pedersen  (was: Jeff Zhang)
    Affects Version/s: 1.0.23.Final
          Component/s: Deployer

    
> Fix NPE of reauthenticationSupport in OutboundResourceAdapterImpl
> -----------------------------------------------------------------
>
>                 Key: JBJCA-1132
>                 URL: https://issues.jboss.org/browse/JBJCA-1132
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common, Deployer
>    Affects Versions: 1.0.23.Final, 1.1.2.Final
>            Reporter: Jeff Zhang
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.3.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 issues at jboss.org  Thu Jan  9 12:03:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 9 Jan 2014 12:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1132) Fix NPE of
 reauthenticationSupport in OutboundResourceAdapterImpl
In-Reply-To: <JIRA.12528629.1388981720000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528629.1388981720000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528629.1388981720000.37087.1389287013069@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-1132.
------------------------------------

    Resolution: Done

    
> Fix NPE of reauthenticationSupport in OutboundResourceAdapterImpl
> -----------------------------------------------------------------
>
>                 Key: JBJCA-1132
>                 URL: https://issues.jboss.org/browse/JBJCA-1132
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common, Deployer
>    Affects Versions: 1.0.23.Final, 1.1.2.Final
>            Reporter: Jeff Zhang
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.3.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 issues at jboss.org  Thu Jan  9 12:07:34 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Thu, 9 Jan 2014 12:07:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238784@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529023.1389287238784@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238784.37100.1389287254018@jira02.app.mwc.hst.phx2.redhat.com>

leonardo lizana created DROOLS-396:
--------------------------------------

             Summary: Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
                 Key: DROOLS-396
                 URL: https://issues.jboss.org/browse/DROOLS-396
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: leonardo lizana
            Assignee: Mark Proctor
            Priority: Critical


I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see the class is on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener.
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>


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

From issues at jboss.org  Thu Jan  9 12:17:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 9 Jan 2014 12:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.37128.1389287852740@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan reassigned WFLY-2733:
--------------------------------

    Assignee: Kabir Khan

    
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> At a minimum IDM and Federation

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

From issues at jboss.org  Thu Jan  9 12:17:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Thu, 9 Jan 2014 12:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.37134.1389287852987@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated WFLY-2733:
-----------------------------

    Assignee:     (was: Kabir Khan)

    
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> At a minimum IDM and Federation

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

From issues at jboss.org  Thu Jan  9 12:17:33 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Jan 2014 12:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.37139.1389287853264@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2733:
-----------------------------------

    Assignee: Pedro Igor

    
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Pedro Igor
>             Fix For: 8.0.0.Final
>
>
> At a minimum IDM and Federation

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

From issues at jboss.org  Thu Jan  9 12:19:32 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 9 Jan 2014 12:19:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2733) Create PicketLink extension
	and subsystems
In-Reply-To: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529014.1389283289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529014.1389283289000.37142.1389287972731@jira02.app.mwc.hst.phx2.redhat.com>


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

Pedro Igor commented on WFLY-2733:
----------------------------------

As discussed with Anil, we're going to provide for this release only the IDM subsystem.
                
> Create PicketLink extension and subsystems
> ------------------------------------------
>
>                 Key: WFLY-2733
>                 URL: https://issues.jboss.org/browse/WFLY-2733
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Pedro Igor
>             Fix For: 8.0.0.Final
>
>
> At a minimum IDM and Federation

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

From issues at jboss.org  Thu Jan  9 12:25:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 12:25:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-215) Clustering tests leave a
 hanging instance if they are run in opposite order
In-Reply-To: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487439.1363626505000.37151.1389288332885@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar updated WFLY-215:
--------------------------------

    Affects Version/s: 8.0.0.Alpha1

    
> Clustering tests leave a hanging instance if they are run in opposite order
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-215
>                 URL: https://issues.jboss.org/browse/WFLY-215
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> Interestingly, if the tests are run in the opposite order i.e. alphabetically, one server instance remains running and doesn't shut down.
> I have used a workaround for now
> {code}
> +                                    <!-- Force the order of tests -->
> +                                    <runOrder>reversealphabetical</runOrder>
> {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 issues at jboss.org  Thu Jan  9 12:25:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 12:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-215) Clustering tests leave a
 hanging instance if they are run in opposite order
In-Reply-To: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487439.1363626505000.37154.1389288333031@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar updated WFLY-215:
--------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> Clustering tests leave a hanging instance if they are run in opposite order
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-215
>                 URL: https://issues.jboss.org/browse/WFLY-215
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> Interestingly, if the tests are run in the opposite order i.e. alphabetically, one server instance remains running and doesn't shut down.
> I have used a workaround for now
> {code}
> +                                    <!-- Force the order of tests -->
> +                                    <runOrder>reversealphabetical</runOrder>
> {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 issues at jboss.org  Thu Jan  9 12:27:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 12:27:33 -0500 (EST)
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.37178.1389288452999@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar closed WFLY-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
>      Security Level: Public(Everyone can see) 
>          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 issues at jboss.org  Thu Jan  9 12:29:33 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 9 Jan 2014 12:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.37185.1389288573449@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins commented on AS7-1389:
------------------------------------

In WildFly there has been a change to disable the adding of logging API's to deployments easier. A new attribute, {{add-logging-api-dependencies}}, has been added to the logging subsystem to easily disable the adding of logging dependencies. The attribute defaults to {{true}}. Changing it to {{false}} will disable the processor from adding any logging API dependencies to deployments. When set to {{false}} any deployment needing a specific logging dependency would require the deployment to add the dependency reference. See https://issues.jboss.org/browse/WFLY-2599 for more details.
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 12:47:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 12:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2484) Revise clustering tests
In-Reply-To: <JIRA.12524748.1384164224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524748.1384164224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524748.1384164224000.37207.1389289653265@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar commented on WFLY-2484:
--------------------------------------

Related idea: we could redesign the tests to use any number of nodes, so that we can test with different number of owners, such that owners < cluster_size. Unfortunately ARQ uses a lot of hard-coded stuff so this makes it quite difficult. Otherwise the framework could be handed over the deployments and take care about it, the client can take random or n-th node for instance.
                
> Revise clustering tests
> -----------------------
>
>                 Key: WFLY-2484
>                 URL: https://issues.jboss.org/browse/WFLY-2484
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> Paul pointed out that some of the tests are no longer relevant with the new implementation and some were never actually relevant, e.g. duplicate tests.
> We should revise the set of tests to keep the testsuite small and find out missing 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 issues at jboss.org  Thu Jan  9 12:47:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 12:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2484) Revise clustering tests
In-Reply-To: <JIRA.12524748.1384164224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524748.1384164224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524748.1384164224000.37209.1389289653358@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar commented on WFLY-2484:
--------------------------------------

(17:27:45) pferraro: rhusar: nor do we need org.jboss.as.test.clustering.extended.ejb2
                
> Revise clustering tests
> -----------------------
>
>                 Key: WFLY-2484
>                 URL: https://issues.jboss.org/browse/WFLY-2484
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> Paul pointed out that some of the tests are no longer relevant with the new implementation and some were never actually relevant, e.g. duplicate tests.
> We should revise the set of tests to keep the testsuite small and find out missing 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 issues at jboss.org  Thu Jan  9 13:41:32 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Thu, 9 Jan 2014 13:41:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238000.37246.1389292892852@jira02.app.mwc.hst.phx2.redhat.com>


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

leonardo lizana updated DROOLS-396:
-----------------------------------

    Description: 
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see the class is on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of 
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>


  was:
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see the class is on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener.
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>



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

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

From issues at jboss.org  Thu Jan  9 14:33:33 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Thu, 9 Jan 2014 14:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.37276.1389296013156@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Hasse commented on AS7-1389:
----------------------------------

I understand JBoss might be more than just a JEE server, but when deploying a JEE application the basic container/application contract should be the JEE specification.  Providing classloader visibility to a specific version of commons logging, log4j and slf4j by default causes problems for the hundreds of applications I work with.  We've implemented isolated classloader repositories on previous EAP versions and still had to open over half a dozen support cases related to broken container isolation related to JBoss-provided logging implementations.

Justifying this decision based on subjective philosophy and community feedback seems to put you down a slippery slope toward including everything and the kitchen sink.  The spec seems like much firmer ground for JEE apps in particular.

> You're talking about users packaging logging libraries with their own configuration which is very definitely not portable behavior anyway. 

Do you still stand by this statement as well?  Because it seems to me you've got it exactly backwards.  Again, logging is not a JEE facility, so packaging your own is the portable approach.

>Since changing it will then be a simple matter...

In my opinion a more correct default would be better than a simple way to change a bad default.

Regards,

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 14:35:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 14:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.37282.1389296132963@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2498:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1029687, https://bugzilla.redhat.com/show_bug.cgi?id=1051171  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1029687)

    
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Thu Jan  9 14:47:32 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 9 Jan 2014 14:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2727) @DataSourceDefinition defined
 data source can't be used in persistence.xml with CDI entity listeners
In-Reply-To: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528884.1389203353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528884.1389203353000.37297.1389296852825@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2727:
------------------------------------

I created the JPA tracker issue at [https://java.net/jira/browse/JPA_SPEC-70].  feedback is welcome. :)
                
> @DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2727
>                 URL: https://issues.jboss.org/browse/WFLY-2727
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Scott Marlow
>
> Defining a data source from within the application using either {{@DataSourceDefinition}} on a class or the {{data-source}} element in {{web.xml}}, and then using this in {{persistence.xml}} will cause a deployment failure.
> E.g.
> {code:xml|title=web.xml}
> <data-source>
>     <name>java:app/MyApp/MyDS</name>
>     <class-name>org.h2.jdbcx.JdbcDataSource</class-name>
>     <url>jdbc:h2:mem:test</url>
> </data-source>
> {code}
> and
> {code:xml|title=persistence.xml}
> <persistence-unit name="testPU">
>     <jta-data-source>java:app/MyApp/MyDS</jta-data-source>
> </persistence-unit>
> {code}
> will result in:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dca783dd-b383-4a16-85a4-1331a2f89354.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "dca783dd-b383-4a16-85a4-1331a2f89354.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dca783dd-b383-4a16-85a4-1331a2f89354.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.dca783dd-b383-4a16-85a4-1331a2f89354.MyApp.MyDS]"]}
> {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 issues at jboss.org  Thu Jan  9 14:51:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Jan 2014 14:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2149) Optimize the SuperUser case
In-Reply-To: <JIRA.12501431.1380052228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501431.1380052228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501431.1380052228000.37299.1389297092707@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2149:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Optimize the SuperUser case
> ---------------------------
>
>                 Key: WFLY-2149
>                 URL: https://issues.jboss.org/browse/WFLY-2149
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 9.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 issues at jboss.org  Thu Jan  9 15:07:32 2014
From: issues at jboss.org (Rossen Stoyanchev (JIRA))
Date: Thu, 9 Jan 2014 15:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2525) Atmosphere connection fails
 using long-polling transport (probable regression from WFLY-2416)
In-Reply-To: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525389.1384748908000.37333.1389298052925@jira02.app.mwc.hst.phx2.redhat.com>


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

Rossen Stoyanchev commented on WFLY-2525:
-----------------------------------------

What commit fixes this and in what release will it be available? The Affects and Fix versions are both set to 8.0.0.CR1, perhaps in error? I searched the git log for comments with WFLY-2525 but didn't find anything. 

I am experiencing the error still (i.e. "UT010026: Async is not supported...") with 8.0.0.CR1. All Servlets and Filters are marked with "asyncSupported" and the same code works in other Servlet 3.0 containers.  


                
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2525
>                 URL: https://issues.jboss.org/browse/WFLY-2525
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat-multiroom
>            Reporter: John Teller
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling.  In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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 issues at jboss.org  Thu Jan  9 15:11:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 15:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.37339.1389298292742@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1594:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=976917, https://bugzilla.redhat.com/show_bug.cgi?id=1051189  (was: https://bugzilla.redhat.com/show_bug.cgi?id=976917)

    
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

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

From issues at jboss.org  Thu Jan  9 15:29:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 15:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.37365.1389299372773@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Shay Matasaro <smatasar at redhat.com> changed the Status of [bug 1029099|https://bugzilla.redhat.com/show_bug.cgi?id=1029099] from NEW to MODIFIED
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Thu Jan  9 15:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 15:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.37380.1389300812811@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1051205|https://bugzilla.redhat.com/show_bug.cgi?id=1051205] from NEW to POST
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Thu Jan  9 15:53:32 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Thu, 9 Jan 2014 15:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238000.37382.1389300812919@jira02.app.mwc.hst.phx2.redhat.com>


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

leonardo lizana updated DROOLS-396:
-----------------------------------

    Description: 
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of org.drools.core.event.DebugProcessEventListener
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>


  was:
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see the class is on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of 
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>



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

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

From issues at jboss.org  Thu Jan  9 15:55:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 15:55:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.37386.1389300932717@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1029099|https://bugzilla.redhat.com/show_bug.cgi?id=1029099] from MODIFIED to POST
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Thu Jan  9 15:55:32 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Thu, 9 Jan 2014 15:55:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238000.37389.1389300932837@jira02.app.mwc.hst.phx2.redhat.com>


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

leonardo lizana updated DROOLS-396:
-----------------------------------

    Description: 
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>


  was:
I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of org.drools.core.event.DebugProcessEventListener
is there anything that i'm doing bad?
* with drools 5.5 everything is working OK.

Here is my pom.xml
--------------------------
<dependency>
			<groupId>org.drools</groupId>
			<artifactId>knowledge-api</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-core</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-compiler</artifactId>
			<version>${drools.version}</version>
		</dependency>
		<dependency>
			<groupId>org.drools</groupId>
			<artifactId>drools-spring</artifactId>
			<version>5.5.0.Final</version>
		</dependency>

here is the log error:
----------------------------
Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

Here is the contex-drools.xml
-------------------------------------
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:drools="http://drools.org/schema/drools-spring"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
    http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
    default-autowire="byName">
     
  <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>

  <drools:kbase id="kBaseEnergyUsage">
    <drools:resources>
      <drools:resource ref="rulesEnergyUsage"/>
    </drools:resources>
  </drools:kbase>
  <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
 </beans>



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

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

From issues at jboss.org  Thu Jan  9 15:59:32 2014
From: issues at jboss.org (Rossen Stoyanchev (JIRA))
Date: Thu, 9 Jan 2014 15:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2525) Atmosphere connection fails
 using long-polling transport (probable regression from WFLY-2416)
In-Reply-To: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525389.1384748908000.37404.1389301172773@jira02.app.mwc.hst.phx2.redhat.com>


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

Rossen Stoyanchev commented on WFLY-2525:
-----------------------------------------

Okay, I found [the commit|https://github.com/undertow-io/undertow/commit/f8440a534a88ecaea53934a366a614df4a3bf589] in the Undertow project. The commit is included in Undertow 1.0.0.Beta25 (and 8.0.0.CR1 is running with Beta30). Nevertheless I'm still experiencing the issue. Is it possible the fix is incomplete because the Filter is not configured for DispatcherType.ASYNC? Looking at the implementation of [FilterHandler.java#L55|https://github.com/undertow-io/undertow/blob/1.0.0.Beta30/servlet/src/main/java/io/undertow/servlet/handlers/FilterHandler.java#L55], that is expected. Here is a [sample project|https://github.com/rstoyanchev/dispatch-test] I'm using.
                
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2525
>                 URL: https://issues.jboss.org/browse/WFLY-2525
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat-multiroom
>            Reporter: John Teller
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling.  In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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 issues at jboss.org  Thu Jan  9 16:35:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 16:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.37436.1389303333008@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2660:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1043667, https://bugzilla.redhat.com/show_bug.cgi?id=1051227  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1043667)

    
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

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

From issues at jboss.org  Thu Jan  9 16:43:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 9 Jan 2014 16:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.37447.1389303813042@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1389:
----------------------------------

{quote}
...basic container/application contract should be the JEE specification... logging is not a JEE facility.... a more correct default would be better than a simple way to change a bad default.
{quote}

None of these arguments really suffices to cause us to change the current default, thus breaking all the apps which currently rely on the current behavior.  We are an application container; we provide application server facilities, many of them above and beyond Java EE.  That's all there is to it.  I'm sure it will be no trouble for anyone who does not prefer the current behavior to simply flip the switch, while allowing those who find the current behavior useful to continue relying on it without breaking compatibility unduly.  I'm sorry you do not like it, however I am not convinced that having to flip a switch in the server configuration based on what is obviously a subjective preference is too onerous or justifies a compatibility-breaking change.  I believe that this solution lets us accommodate both preferences with ease and without undue burden on the user.

Again, we're an application container.  We support a superset of the Java EE specification; and in any case the Java EE specification in no way limits or specifies what secondary APIs we can or should provide to users.
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 17:07:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 17:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.37454.1389305252902@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2660:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1043667, https://bugzilla.redhat.com/show_bug.cgi?id=1051227, https://bugzilla.redhat.com/show_bug.cgi?id=1051240  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1043667, https://bugzilla.redhat.com/show_bug.cgi?id=1051227)

    
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

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

From issues at jboss.org  Thu Jan  9 17:31:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 17:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.37488.1389306692887@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from POST to MODIFIED
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {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 issues at jboss.org  Thu Jan  9 17:37:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Jan 2014 17:37:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-215) Clustering tests leave a
 hanging instance if they are run in opposite order
In-Reply-To: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487439.1363626505000.37495.1389307052788@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar updated WFLY-215:
--------------------------------

    Issue Type: Bug  (was: Enhancement)

    
> Clustering tests leave a hanging instance if they are run in opposite order
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-215
>                 URL: https://issues.jboss.org/browse/WFLY-215
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> Interestingly, if the tests are run in the opposite order i.e. alphabetically, one server instance remains running and doesn't shut down.
> I have used a workaround for now
> {code}
> +                                    <!-- Force the order of tests -->
> +                                    <runOrder>reversealphabetical</runOrder>
> {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 issues at jboss.org  Thu Jan  9 17:45:33 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Thu, 9 Jan 2014 17:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.37502.1389307533460@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Hasse commented on AS7-1389:
----------------------------------

> We are an application container; we provide application server facilities, many of them above and beyond Java EE.
Can you provide specific examples of this for a JEE web app for instance?  https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Development_Guide/sect-Reference.html#Implicit_Module_Dependencies would seem to imply that the only outliers in terms of being explicitly provided outside of the spec are related to logging.  Likewise neither EJB3 nor EE deployments seem to have anything implicitly provided beyond the spec except for logging.  So for the topic at hand (JEE deployments) I'm not sure what these many above and beyond facilities would be.  I'm sure there are other non-JEE deployment types where providing logging might be appropriate, but if that is appropriate for those then by all means provide as many logging APIs and implementations implicitly for them as is appropriate.

Anyway if you are providing vendor-specific facilities above and beyond the spec for JEE apps is it not most reasonable and correct to have the applications making use of those vendor-specific extensions be the ones that have to explicitly specify something?

> I'm sure it will be no trouble for anyone who does not prefer the current behavior to simply flip the switch
I don't believe that switch you suggest we flip currently exists in EAP 6.2 or any currently released EAP.  In the mean time every application we develop will need to have a JBoss-specific deployment descriptor embedded, putting it in a non-default and less-well-tested configuration and giving us work to do during future migrations.

> the Java EE specification in no way limits or specifies what secondary APIs we can or should provide to users.
True, but common sense should, and you almost got it fully correct in EAP 6, except it seems for logging.

Regards,

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 17:57:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 9 Jan 2014 17:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.37510.1389308253068@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1389:
----------------------------------

Scott, I'm not going to argue about it.  You seem to feel bitter about it and you apparently believe that your viewpoint is "common sense" and thus there's no way to pursue the discussion rationally beyond what was already said.

I can tell you that if you're curious about what APIs are visible from a deployment, you can examine (in JConsole) the JBoss Modules MBean corresponding to the service module loader, and find a deployment module and look at its dependencies.  That may give you an idea of what facilities are available to applications.

As for the change not being in EAP - assuming that the proper RFE process is followed, it is not unreasonable to expect this change to be backported, same as any requested feature or enhancement.
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Thu Jan  9 18:05:32 2014
From: issues at jboss.org (David Hatten (JIRA))
Date: Thu, 9 Jan 2014 18:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2734) Unable to use --runtime_name
 in jboss-cli deploy command
In-Reply-To: <JIRA.12529045.1389308716767@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529045.1389308716767@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529045.1389308716767.37512.1389308732681@jira02.app.mwc.hst.phx2.redhat.com>

David Hatten created WFLY-2734:
----------------------------------

             Summary: Unable to use --runtime_name in jboss-cli deploy command
                 Key: WFLY-2734
                 URL: https://issues.jboss.org/browse/WFLY-2734
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Running on Windows 7
            Reporter: David Hatten


When using the jboss-cli utility, I am unable to use the --runtime_name parameter to specify a Runtime Name. I have tried the following configurations:

1) Deploy a war using both --name and --runtime_name. When I view the deployment in the admin console, both the Name and Runtime Name fields are set to the value of --name

2) Deploy a war using only --runtime_name parameter. When I view the deployment in the admin console, the Runtime Name is the name of the file being deployed.

In both cases, the specified value of --runtime_name is ignored. I believe this is a bug and not a configuration 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 issues at jboss.org  Thu Jan  9 18:17:32 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 9 Jan 2014 18:17:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2734) Unable to use --runtime_name
 in jboss-cli deploy command
In-Reply-To: <JIRA.12529045.1389308716000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529045.1389308716000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529045.1389308716000.37564.1389309452855@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins commented on WFLY-2734:
-------------------------------------

I believe it should be {{--runtime-name}}. Note the dash instead of the underscore.
                
> Unable to use --runtime_name in jboss-cli deploy command
> --------------------------------------------------------
>
>                 Key: WFLY-2734
>                 URL: https://issues.jboss.org/browse/WFLY-2734
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Running on Windows 7
>            Reporter: David Hatten
>              Labels: jboss, jboss-as
>
> When using the jboss-cli utility, I am unable to use the --runtime_name parameter to specify a Runtime Name. I have tried the following configurations:
> 1) Deploy a war using both --name and --runtime_name. When I view the deployment in the admin console, both the Name and Runtime Name fields are set to the value of --name
> 2) Deploy a war using only --runtime_name parameter. When I view the deployment in the admin console, the Runtime Name is the name of the file being deployed.
> In both cases, the specified value of --runtime_name is ignored. I believe this is a bug and not a configuration 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 issues at jboss.org  Thu Jan  9 18:45:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 18:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.37589.1389311133398@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Derek Horton <dehort at redhat.com> changed the Status of [bug 1051240|https://bugzilla.redhat.com/show_bug.cgi?id=1051240] from NEW to POST
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

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

From issues at jboss.org  Thu Jan  9 18:47:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 18:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.37594.1389311252948@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Derek Horton <dehort at redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from NEW to POST
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

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

From issues at jboss.org  Thu Jan  9 19:01:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 19:01:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.37599.1389312092900@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1049999|https://bugzilla.redhat.com/show_bug.cgi?id=1049999] from NEW to POST
                
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Thu Jan  9 19:03:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 9 Jan 2014 19:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.37602.1389312212953@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1050003|https://bugzilla.redhat.com/show_bug.cgi?id=1050003] from NEW to POST
                
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Fri Jan 10 00:23:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 00:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager
 module needs a dependency on javax.mail.api
In-Reply-To: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490786.1367277432000.37752.1389331412819@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1300:
------------------------------------------

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

    
> org.jboss.log4j.logmanager module needs a dependency on javax.mail.api
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1300
>                 URL: https://issues.jboss.org/browse/WFLY-1300
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too.

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

From issues at jboss.org  Fri Jan 10 00:31:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 00:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager
 module needs a dependency on javax.mail.api
In-Reply-To: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490786.1367277432000.37775.1389331892771@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1051335|https://bugzilla.redhat.com/show_bug.cgi?id=1051335] from NEW to POST
                
> org.jboss.log4j.logmanager module needs a dependency on javax.mail.api
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1300
>                 URL: https://issues.jboss.org/browse/WFLY-1300
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too.

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

From issues at jboss.org  Fri Jan 10 02:30:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Jan 2014 02:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2525) Atmosphere connection fails
 using long-polling transport (probable regression from WFLY-2416)
In-Reply-To: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525389.1384748908000.37780.1389339033233@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2525:
--------------------------------------

See UNDERTOW-171
                
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2525
>                 URL: https://issues.jboss.org/browse/WFLY-2525
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat-multiroom
>            Reporter: John Teller
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling.  In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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 issues at jboss.org  Fri Jan 10 03:24:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Jan 2014 03:24:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2596) JASPI Web layer problems
In-Reply-To: <JIRA.12526667.1386018631000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526667.1386018631000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526667.1386018631000.37851.1389342273197@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2596:
------------------------------------

    Assignee: Stefan Guilhen  (was: Stuart Douglas)


Stefan is looking at the remaining failures
                
> JASPI Web layer problems
> ------------------------
>
>                 Key: WFLY-2596
>                 URL: https://issues.jboss.org/browse/WFLY-2596
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Fedora 19, x86_64
>            Reporter: Istv?n T?th
>            Assignee: Stefan Guilhen
>
> I have found several problems in the current (master, trunk) Wildfly JASPI Web layer implementation
> Undertow related:
> ----------------------
>  * It does not support pre-emptive authentication: 
> When the ServerAuthenticationModule returns AUTH_SUCCESS and null userPrincipal, it should let the request fall through unathenticated, instead it is rejected.
>  * It does not call secureResponse when the authentication was unsuccessful
>  * It does not populate the org.jboss.security.SecurityContext, only the undertow Account structure.
>  * It does not support the wrapper feature (Spec 3.8.3.5 and B.9)
> The attached pull request aims to fix the first three issues.
> Credits: This patch is based on Arjan Tijms' analysis, and suggested patches for the Jboss 7.X valve based authentitactor.

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


From issues at jboss.org  Fri Jan 10 04:06:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 04:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-374) WM Corruption when events
 are modified - was Bug in the expiration offset calculation
In-Reply-To: <JIRA.12527702.1386773434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527702.1386773434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527702.1386773434000.37896.1389344793294@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1043481|https://bugzilla.redhat.com/show_bug.cgi?id=1043481] from ON_QA to VERIFIED
                
> WM Corruption when events are modified - was Bug in the expiration offset calculation 
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-374
>                 URL: https://issues.jboss.org/browse/DROOLS-374
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Thorsten Kunz
>            Assignee: Mario Fusco
>              Labels: event, expiration, fusion
>             Fix For: 6.0.1.Final
>
>         Attachments: drools-event-expiration-test.zip
>
>
> In some cases there seems to be a bug when an @expires annotation is set on an event class and it is not expired by the time set in the annotation but what time it is possibly matched in a sliding window.
> I'll attach a simple test case that demonstrates when the @expires annotation is 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 issues at jboss.org  Fri Jan 10 04:35:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Jan 2014 04:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2642) Improve Spring and RestEasy
	integration
In-Reply-To: <JIRA.12527787.1386848475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527787.1386848475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527787.1386848475000.37948.1389346532909@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2642:
--------------------------------------

I have implemented this, basically it just adds the resteasy-spring jar as a resource root if a spring servlet/listener is present and jax-rs is in use. 

I have tested it against the Resteasy spring example and it appears to work. 


                
> Improve Spring and RestEasy integration
> ---------------------------------------
>
>                 Key: WFLY-2642
>                 URL: https://issues.jboss.org/browse/WFLY-2642
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: REST
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>             Fix For: 8.0.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 issues at jboss.org  Fri Jan 10 04:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 04:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-378) Do not refire rules on
	unblock
In-Reply-To: <JIRA.12527977.1387077235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527977.1387077235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527977.1387077235000.38012.1389347612744@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas David <tdavid at redhat.com> changed the Status of [bug 1038076|https://bugzilla.redhat.com/show_bug.cgi?id=1038076] from ON_QA to VERIFIED
                
> Do not refire rules on unblock
> ------------------------------
>
>                 Key: DROOLS-378
>                 URL: https://issues.jboss.org/browse/DROOLS-378
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>
> If a rule is blocked (using the declarative agenda) after it has been fired, it will refire when the blocker is 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 issues at jboss.org  Fri Jan 10 05:47:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Jan 2014 05:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1390) Undertow: javamelody
 SessionListener stop working
In-Reply-To: <JIRA.12492613.1369328397000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492613.1369328397000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492613.1369328397000.38081.1389350852782@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-1390.
----------------------------------

    Resolution: Out of Date


Wildly no longer contains OSGI support in the core distribution.
                
> Undertow: javamelody SessionListener stop working
> -------------------------------------------------
>
>                 Key: WFLY-1390
>                 URL: https://issues.jboss.org/browse/WFLY-1390
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Igor Shulika
>            Assignee: Stuart Douglas
>         Attachments: jaffa-3rd-party-javamelody-core-1.43.0.jar, jaffa-sample-webapp-6.0.jar
>
>
> I'm deploying JavaMelody OSGi bundle on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Since I switch from Jbossweb to Undertow the JavaMelody SessionListener stop working.
> Please see below configuration in the web.xml file.
>   <listener>
>     <listener-class>net.bull.javamelody.SessionListener</listener-class>
>   </listener>
> Please see error trace below.
> Note: It works in Jbossweb.
> Thanks!
> 09:51:44,005 INFO  [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: org.test.sample.webapp.my-sample-webapp:6.0.0
> 09:52:15,221 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC000001: Failed to start service jboss.deployment.unit."my-sample-webapp-6.0.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."my-sample-webapp-6.0.jar".Activate: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [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: org.jboss.osgi.deployment.interceptor.LifecycleInterceptorException: JBAS017345: Timeout context service activation: service jboss.undertow.deployment.default-host./test
> 	at org.jboss.as.osgi.web.WebContextLifecycleInterceptor.invoke(WebContextLifecycleInterceptor.java:105)
> 	at org.jboss.osgi.deployment.interceptor.AbstractLifecycleInterceptorService.handleStateChange(AbstractLifecycleInterceptorService.java:264)
> 	at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:253)
> 	at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:242)
> 	at org.jboss.osgi.framework.internal.UserBundleState.startInternalNow(UserBundleState.java:637)
> 	at org.jboss.osgi.framework.internal.UserBundleState.startInternal(UserBundleState.java:526)
> 	at org.jboss.osgi.framework.internal.BundleManagerPlugin.startBundle(BundleManagerPlugin.java:560)
> 	at org.jboss.as.osgi.deployment.BundleActivateProcessor$BundleActivateService.start(BundleActivateProcessor.java:125)
> 	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]
> 	... 3 more
> Caused by: java.util.concurrent.TimeoutException: JBAS017345: Timeout context service activation: service jboss.undertow.deployment.default-host./jaffa
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$ContextActivatorImpl.start(UndertowDeploymentService.java:158)
> 	at org.jboss.as.osgi.web.WebContextLifecycleInterceptor.invoke(WebContextLifecycleInterceptor.java:100)
> 	... 12 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 issues at jboss.org  Fri Jan 10 06:27:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Jan 2014 06:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2720) Ability for Deployment
 Overlays to overlay System Properties
In-Reply-To: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528797.1389126869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528797.1389126869000.38138.1389353252926@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2720:
--------------------------------------

I doubt we could do this with 'System properties' as such, as system properties are global and not per-deployment. Potentially we could do this just for property replacement in descriptors. 
                
> Ability for Deployment Overlays to overlay System Properties
> ------------------------------------------------------------
>
>                 Key: WFLY-2720
>                 URL: https://issues.jboss.org/browse/WFLY-2720
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Joshua Henn
>             Fix For: 8.0.0.Final
>
>
> Currently Deployment Overlays allow only the replacing whole resource files.  It would be nice to also be able to overlay System Properties that take precedent over globally defined properties.
> ie.
> {code:xml}
>     <deployment-overlays>
>         <deployment-overlay name="myOverlay">
>             <system-properties>
>                 <property name="datasource" value="java:jboss/datasources/controller"/>
>             </system-properties>
>             <deployment name="controller.war"/>
>         </deployment-overlay>
>     </deployment-overlays>
> {code}
> Usecase:
> Have two deployments active of the same application, run-time configured by descriptor replacements via System 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 issues at jboss.org  Fri Jan 10 06:43:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 06:43:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.38161.1389354212764@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1051171|https://bugzilla.redhat.com/show_bug.cgi?id=1051171] from NEW to ASSIGNED
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan 10 06:47:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 06:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-370) Declarative Agenda control
 does not support all possible constraints
In-Reply-To: <JIRA.12527286.1386457535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527286.1386457535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527286.1386457535000.38165.1389354452862@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1042926|https://bugzilla.redhat.com/show_bug.cgi?id=1042926] from ON_QA to VERIFIED
                
> Declarative Agenda control does not support all possible constraints
> --------------------------------------------------------------------
>
>                 Key: DROOLS-370
>                 URL: https://issues.jboss.org/browse/DROOLS-370
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            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 issues at jboss.org  Fri Jan 10 07:07:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Jan 2014 07:07:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2714) EL Comparison don't works in
	attributes
In-Reply-To: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528682.1389035131000.38181.1389355652754@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2714.
----------------------------------

    Resolution: Cannot Reproduce Bug


Just tried this out and it works fine for me. If you are still having issues please attach a reproducer and re-open.
                
> EL Comparison don't works in attributes
> ---------------------------------------
>
>                 Key: WFLY-2714
>                 URL: https://issues.jboss.org/browse/WFLY-2714
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> Wildfly 8.0.0 CR1
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>              Labels: el, wildfly
>
> I have a class with BigDecimal attribute:
> {code:java}
> public class Foo {
>     private BigDecimal value;
> }
> {code}
> This code works fine
> {code:xml}
> <p>${foo.value lt 0}</p>
> {code}
> And this code too:
> {code:xml}
> <p>${foo.value lt 0 ? 'negative' : 'positive'}</p>
> {code}
> But when I use the expression in the attribute, I get the errot bellow:
> {code:xml}
> <p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>
> {code}
> The class 'Foo' does not have the property 'valuelt0'.

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


From issues at jboss.org  Fri Jan 10 07:11:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 10 Jan 2014 07:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1770) Table: null row when removing
	last element
In-Reply-To: <JIRA.12529083.1389355874994@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529083.1389355874994@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529083.1389355874994.38183.1389355892714@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1770:
------------------------------

             Summary: Table: null row when removing last element
                 Key: JGRP-1770
                 URL: https://issues.jboss.org/browse/JGRP-1770
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
Note that Table.purge() actually does null entire rows, this is called by
* NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
* UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either

The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.

SOLUTION:
When {{Table.removeMany()}} nulls an element, if that element is tha last element of a row (index = {{elements_per_row -1}}, then null the entire row.

EFFECT:
There's less memory held in memory by UNICAST3 receiver 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 issues at jboss.org  Fri Jan 10 07:31:32 2014
From: issues at jboss.org (Sumanth M S (JIRA))
Date: Fri, 10 Jan 2014 07:31:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2448) Print IOR to a user specified
	file
In-Reply-To: <JIRA.12518153.1383748388000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518153.1383748388000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518153.1383748388000.38209.1389357092872@jira02.app.mwc.hst.phx2.redhat.com>


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

Sumanth M S updated WFLY-2448:
------------------------------

    Attachment: WFLY-2448.patch


I have attached enhancement as a .patch file. Please let me know your observations or if actual source can be attached
                
> Print IOR to a user specified file
> ----------------------------------
>
>                 Key: WFLY-2448
>                 URL: https://issues.jboss.org/browse/WFLY-2448
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows, Solaris, Linux
>            Reporter: Sumanth M S
>            Assignee: Stefan Guilhen
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>         Attachments: WFLY-2448.patch
>
>
> Jboss AS prints Corba IOR on console or log file. Many applications look for a file at a predefined location from where it can read the IOR; as it is difficult to read IOR programatically from a log file or console.
> An environment variable can be defined in standalone.conf to let the user specify the file location to which JBoss will print the IOR along with printing on the console.
> The solution has been tried and seems working. Please let us know if the solution can be submitted.

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

From issues at jboss.org  Fri Jan 10 07:51:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 07:51:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2431) Console flipping to
 "jboss-ejb-policy" when select other security domain
In-Reply-To: <JIRA.12510975.1383331118000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12510975.1383331118000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12510975.1383331118000.38278.1389358295638@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Harald Pehl <hpehl at redhat.com> changed the Status of [bug 1048211|https://bugzilla.redhat.com/show_bug.cgi?id=1048211] from NEW to ASSIGNED
                
> Console flipping to "jboss-ejb-policy" when select other security domain 
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2431
>                 URL: https://issues.jboss.org/browse/WFLY-2431
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 8.0.0.Beta1
>         Environment: Linux x64 (Fedora), server started with standalone.xml profile
>            Reporter: dometec
>            Assignee: Heiko Braun
>            Priority: Minor
>              Labels: Console, Web
>         Attachments: wildfly-console.flipping.ogv
>
>
> Console flipping to "jboss-ejb-policy" when select other 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 issues at jboss.org  Fri Jan 10 07:59:33 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Fri, 10 Jan 2014 07:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2653) HTTPS undertow listener
 select cipher-suites
In-Reply-To: <JIRA.12527942.1386949860000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527942.1386949860000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527942.1386949860000.38303.1389358773607@jira02.app.mwc.hst.phx2.redhat.com>


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

Aleksandar Kostadinov commented on WFLY-2653:
---------------------------------------------

Any progress with the PR?
                
> HTTPS undertow listener select cipher-suites
> --------------------------------------------
>
>                 Key: WFLY-2653
>                 URL: https://issues.jboss.org/browse/WFLY-2653
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: fedora 18
>            Reporter: Aleksandar Kostadinov
>            Assignee: Tomaz Cerar
>              Labels: https, security, security-hardening, ssl, undertow, wildfly
>             Fix For: 8.0.0.CR1
>
>
> At the moment I don't see any way to restrict allowed cipher suites for the https listener.
> {CODE}
> [standalone at localhost:9990 /] /core-service=management/security-realm=HttpsRealm:read-resource(recursive=true, include-defaults=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "map-groups-to-roles" => true,
>         "authentication" => undefined,
>         "authorization" => undefined,
>         "plug-in" => undefined,
>         "server-identity" => {"ssl" => {
>             "alias" => undefined,
>             "key-password" => undefined,
>             "keystore-password" => "changeit",
>             "keystore-path" => "localhost.keystore",
>             "keystore-relative-to" => "jboss.server.config.dir",
>             "protocol" => "TLS"
>         }}
>     }
> }
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server:read-resource(recursive=true, include-defaults=true)
> {
>     "outcome" => "success",
>     "result" => {
> <...>
>         "https-listener" => {"https" => {
>             "allow-encoded-slash" => false,
>             "always-set-keep-alive" => true,
>             "buffer-pipelined-data" => true,
>             "buffer-pool" => "default",
>             "decode-url" => true,
>             "enabled" => true,
>             "max-cookies" => 200,
>             "max-header-size" => 51200,
>             "max-headers" => 200,
>             "max-parameters" => 1000,
>             "max-post-size" => 10485760L,
>             "security-realm" => "ApplicationRealm",
>             "socket-binding" => "https",
>             "url-charset" => "UTF-8",
>             "verify-client" => "NOT_REQUESTED",
>             "worker" => "default"
>         }}
>     }
> }
> {CODE}
> I have tested that default cipher suites used are pretty sane except RC4-SHA and RC4-MD5. Below is full list. But I think it is important for users to be able to support more or less ciphers depending on their environment and requirements. We also need good secure default settings IMO excluding the above mentioned two ciphers. See current recommendations here [1][2]
> {CODE}
> $ sslscan --no-failed localhost:8443
>                    _
>            ___ ___| |___  ___ __ _ _ __
>           / __/ __| / __|/ __/ _` | '_ \
>           \__ \__ \ \__ \ (_| (_| | | | |
>           |___/___/_|___/\___\__,_|_| |_|
>                   Version 1.8.2
>              http://www.titania.co.uk
>         Copyright Ian Ventura-Whiting 2009
> Testing SSL server localhost on port 8443
>   Supported Server Cipher(s):
>     Accepted  SSLv3  256 bits  DHE-RSA-AES256-SHA
>     Accepted  SSLv3  256 bits  AES256-SHA
>     Accepted  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
>     Accepted  SSLv3  168 bits  DES-CBC3-SHA
>     Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
>     Accepted  SSLv3  128 bits  AES128-SHA
>     Accepted  SSLv3  128 bits  RC4-SHA
>     Accepted  SSLv3  128 bits  RC4-MD5
>     Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
>     Accepted  TLSv1  256 bits  AES256-SHA
>     Accepted  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
>     Accepted  TLSv1  168 bits  DES-CBC3-SHA
>     Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
>     Accepted  TLSv1  128 bits  AES128-SHA
>     Accepted  TLSv1  128 bits  RC4-SHA
>     Accepted  TLSv1  128 bits  RC4-MD5
> {CODE}
> [1] http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html-single/Defensive_Coding/index.html#chap-Defensive_Coding-Tasks-Cryptography
> [2] http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html-single/Defensive_Coding/index.html#sect-Defensive_Coding-TLS-Client-OpenJDK

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

From issues at jboss.org  Fri Jan 10 08:01:35 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 10 Jan 2014 08:01:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2653) HTTPS undertow listener
 select cipher-suites
In-Reply-To: <JIRA.12527942.1386949860000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527942.1386949860000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527942.1386949860000.38313.1389358895099@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-2653:
-----------------------------------

PR was merged, issue resolved and it is part of CR1 release
                
> HTTPS undertow listener select cipher-suites
> --------------------------------------------
>
>                 Key: WFLY-2653
>                 URL: https://issues.jboss.org/browse/WFLY-2653
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: fedora 18
>            Reporter: Aleksandar Kostadinov
>            Assignee: Tomaz Cerar
>              Labels: https, security, security-hardening, ssl, undertow, wildfly
>             Fix For: 8.0.0.CR1
>
>
> At the moment I don't see any way to restrict allowed cipher suites for the https listener.
> {CODE}
> [standalone at localhost:9990 /] /core-service=management/security-realm=HttpsRealm:read-resource(recursive=true, include-defaults=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "map-groups-to-roles" => true,
>         "authentication" => undefined,
>         "authorization" => undefined,
>         "plug-in" => undefined,
>         "server-identity" => {"ssl" => {
>             "alias" => undefined,
>             "key-password" => undefined,
>             "keystore-password" => "changeit",
>             "keystore-path" => "localhost.keystore",
>             "keystore-relative-to" => "jboss.server.config.dir",
>             "protocol" => "TLS"
>         }}
>     }
> }
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server:read-resource(recursive=true, include-defaults=true)
> {
>     "outcome" => "success",
>     "result" => {
> <...>
>         "https-listener" => {"https" => {
>             "allow-encoded-slash" => false,
>             "always-set-keep-alive" => true,
>             "buffer-pipelined-data" => true,
>             "buffer-pool" => "default",
>             "decode-url" => true,
>             "enabled" => true,
>             "max-cookies" => 200,
>             "max-header-size" => 51200,
>             "max-headers" => 200,
>             "max-parameters" => 1000,
>             "max-post-size" => 10485760L,
>             "security-realm" => "ApplicationRealm",
>             "socket-binding" => "https",
>             "url-charset" => "UTF-8",
>             "verify-client" => "NOT_REQUESTED",
>             "worker" => "default"
>         }}
>     }
> }
> {CODE}
> I have tested that default cipher suites used are pretty sane except RC4-SHA and RC4-MD5. Below is full list. But I think it is important for users to be able to support more or less ciphers depending on their environment and requirements. We also need good secure default settings IMO excluding the above mentioned two ciphers. See current recommendations here [1][2]
> {CODE}
> $ sslscan --no-failed localhost:8443
>                    _
>            ___ ___| |___  ___ __ _ _ __
>           / __/ __| / __|/ __/ _` | '_ \
>           \__ \__ \ \__ \ (_| (_| | | | |
>           |___/___/_|___/\___\__,_|_| |_|
>                   Version 1.8.2
>              http://www.titania.co.uk
>         Copyright Ian Ventura-Whiting 2009
> Testing SSL server localhost on port 8443
>   Supported Server Cipher(s):
>     Accepted  SSLv3  256 bits  DHE-RSA-AES256-SHA
>     Accepted  SSLv3  256 bits  AES256-SHA
>     Accepted  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
>     Accepted  SSLv3  168 bits  DES-CBC3-SHA
>     Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
>     Accepted  SSLv3  128 bits  AES128-SHA
>     Accepted  SSLv3  128 bits  RC4-SHA
>     Accepted  SSLv3  128 bits  RC4-MD5
>     Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
>     Accepted  TLSv1  256 bits  AES256-SHA
>     Accepted  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
>     Accepted  TLSv1  168 bits  DES-CBC3-SHA
>     Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
>     Accepted  TLSv1  128 bits  AES128-SHA
>     Accepted  TLSv1  128 bits  RC4-SHA
>     Accepted  TLSv1  128 bits  RC4-MD5
> {CODE}
> [1] http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html-single/Defensive_Coding/index.html#chap-Defensive_Coding-Tasks-Cryptography
> [2] http://docs.fedoraproject.org/en-US/Fedora_Security_Team//html-single/Defensive_Coding/index.html#sect-Defensive_Coding-TLS-Client-OpenJDK

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

From issues at jboss.org  Fri Jan 10 08:33:33 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Fri, 10 Jan 2014 08:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2735) read-operation-names casues
 NullPointerException
In-Reply-To: <JIRA.12529095.1389360809517@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529095.1389360809517@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529095.1389360809517.38366.1389360813083@jira02.app.mwc.hst.phx2.redhat.com>

Stan Silvert created WFLY-2735:
----------------------------------

             Summary: read-operation-names casues NullPointerException
                 Key: WFLY-2735
                 URL: https://issues.jboss.org/browse/WFLY-2735
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Final
            Reporter: Stan Silvert
            Assignee: Brian Stansberry


CLI command> /core-service=*/:read-operation-names

08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
e-service" => "*")]): java.lang.NullPointerException
        at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
.0.Final-SNAPSHOT]
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
OT]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
PSHOT]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
al-SNAPSHOT]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
NAPSHOT]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
        at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
        at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
        at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
T]
        at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
NAPSHOT]
        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.1.Final.jar:2.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 issues at jboss.org  Fri Jan 10 08:35:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 10 Jan 2014 08:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2735) read-operation-names casues
 NullPointerException
In-Reply-To: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529095.1389360809000.38371.1389360932873@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2735:
------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> read-operation-names casues NullPointerException
> ------------------------------------------------
>
>                 Key: WFLY-2735
>                 URL: https://issues.jboss.org/browse/WFLY-2735
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
>         at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>         at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         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.1.Final.jar:2.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 issues at jboss.org  Fri Jan 10 08:59:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 08:59:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.38417.1389362373204@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1049074|https://bugzilla.redhat.com/show_bug.cgi?id=1049074] from POST to MODIFIED
                
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

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

From issues at jboss.org  Fri Jan 10 09:01:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 09:01:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.38420.1389362494318@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1032627|https://bugzilla.redhat.com/show_bug.cgi?id=1032627] from POST to MODIFIED
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {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 issues at jboss.org  Fri Jan 10 09:01:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 09:01:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager
 module needs a dependency on javax.mail.api
In-Reply-To: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490786.1367277432000.38422.1389362494460@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1051335|https://bugzilla.redhat.com/show_bug.cgi?id=1051335] from POST to MODIFIED
                
> org.jboss.log4j.logmanager module needs a dependency on javax.mail.api
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1300
>                 URL: https://issues.jboss.org/browse/WFLY-1300
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too.

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

From issues at jboss.org  Fri Jan 10 09:25:34 2014
From: issues at jboss.org (David Hatten (JIRA))
Date: Fri, 10 Jan 2014 09:25:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2734) Unable to use --runtime_name
 in jboss-cli deploy command
In-Reply-To: <JIRA.12529045.1389308716000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529045.1389308716000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529045.1389308716000.38535.1389363934660@jira02.app.mwc.hst.phx2.redhat.com>


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

David Hatten commented on WFLY-2734:
------------------------------------

That makes a lot more sense. The help text reads --runtime_name. Attaching picture.

http://imgur.com/rHDzrjm
                
> Unable to use --runtime_name in jboss-cli deploy command
> --------------------------------------------------------
>
>                 Key: WFLY-2734
>                 URL: https://issues.jboss.org/browse/WFLY-2734
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Running on Windows 7
>            Reporter: David Hatten
>              Labels: jboss, jboss-as
>
> When using the jboss-cli utility, I am unable to use the --runtime_name parameter to specify a Runtime Name. I have tried the following configurations:
> 1) Deploy a war using both --name and --runtime_name. When I view the deployment in the admin console, both the Name and Runtime Name fields are set to the value of --name
> 2) Deploy a war using only --runtime_name parameter. When I view the deployment in the admin console, the Runtime Name is the name of the file being deployed.
> In both cases, the specified value of --runtime_name is ignored. I believe this is a bug and not a configuration 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 issues at jboss.org  Fri Jan 10 09:27:33 2014
From: issues at jboss.org (Rossen Stoyanchev (JIRA))
Date: Fri, 10 Jan 2014 09:27:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2525) Atmosphere connection fails
 using long-polling transport (probable regression from WFLY-2416)
In-Reply-To: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525389.1384748908000.38633.1389364053205@jira02.app.mwc.hst.phx2.redhat.com>


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

Rossen Stoyanchev commented on WFLY-2525:
-----------------------------------------

Thanks, I was able to confirm the fix with Beta32 snapshot. Should the fix version here be 8.0.0.CR2? I presume Wildfly has a fixed version of Undertow.
                
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2525
>                 URL: https://issues.jboss.org/browse/WFLY-2525
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat-multiroom
>            Reporter: John Teller
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling.  In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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 issues at jboss.org  Fri Jan 10 09:29:33 2014
From: issues at jboss.org (Rossen Stoyanchev (JIRA))
Date: Fri, 10 Jan 2014 09:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2525) Atmosphere connection fails
 using long-polling transport (probable regression from WFLY-2416)
In-Reply-To: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525389.1384748908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525389.1384748908000.38639.1389364173035@jira02.app.mwc.hst.phx2.redhat.com>


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

Rossen Stoyanchev edited comment on WFLY-2525 at 1/10/14 9:28 AM:
------------------------------------------------------------------

Thanks, I was able to confirm the fix with Beta32 snapshot. Should the fix version here be 8.0.0.CR2? I presume the version of Undertow in 8.0.0.CR1 will not change.
                
      was (Author: rstoyanchev):
    Thanks, I was able to confirm the fix with Beta32 snapshot. Should the fix version here be 8.0.0.CR2? I presume Wildfly has a fixed version of Undertow.
                  
> Atmosphere connection fails using long-polling transport (probable regression from WFLY-2416)
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2525
>                 URL: https://issues.jboss.org/browse/WFLY-2525
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #786 (undertow 1.0.0.beta23)
> atmosphere chat-multiroom sample:
> https://github.com/Atmosphere/atmosphere-samples/tree/master/samples/chat-multiroom
>            Reporter: John Teller
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> In previous Atmosphere tests with undertow beta20, attempting to connect using websocket transport failed, then fell back successfully to long-polling.  In latest test with undertow beta23, websocket transport now works correctly, but attempting to connect using long-polling transport now results in the following error:
> 2013-11-17 21:57:32,857 ERROR [org.atmosphere.cpr.AtmosphereFramework] (default task-6) AtmosphereFramework exception: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:909) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:503) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:128) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1684) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:198) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:184) [atmosphere-runtime-2.0.3.jar:2.0.3]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:114) [undertow-websockets-jsr-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145) [undertow-servlet-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:637) [undertow-core-1.0.0.Beta23.jar:1.0.0.Beta23]
> 	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 issues at jboss.org  Fri Jan 10 09:39:32 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jan 2014 09:39:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1133) IronJacamar 1.1.3.Final
In-Reply-To: <JIRA.12529105.1389364757144@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529105.1389364757144@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529105.1389364757144.38669.1389364772767@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1133:
--------------------------------------

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


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

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

From issues at jboss.org  Fri Jan 10 09:41:32 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jan 2014 09:41:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1133) IronJacamar 1.1.3.Final
In-Reply-To: <JIRA.12529105.1389364757000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529105.1389364757000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529105.1389364757000.38672.1389364892770@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-1133.
------------------------------------

    Resolution: Done

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

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

From issues at jboss.org  Fri Jan 10 09:41:32 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jan 2014 09:41:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1130) Track component updates
In-Reply-To: <JIRA.12528378.1387812865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528378.1387812865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528378.1387812865000.38675.1389364892914@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-1130.
------------------------------------

    Resolution: Done

    
> Track component updates
> -----------------------
>
>                 Key: JBJCA-1130
>                 URL: https://issues.jboss.org/browse/JBJCA-1130
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.3.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 issues at jboss.org  Fri Jan 10 09:41:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jan 2014 09:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1131) Narayana 5.0.0.CR2
In-Reply-To: <JIRA.12528379.1387812906000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528379.1387812906000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528379.1387812906000.38677.1389364893022@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-1131.
------------------------------------

    Resolution: Done

    
> Narayana 5.0.0.CR2
> ------------------
>
>                 Key: JBJCA-1131
>                 URL: https://issues.jboss.org/browse/JBJCA-1131
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.3.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 issues at jboss.org  Fri Jan 10 09:49:33 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Fri, 10 Jan 2014 09:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.38695.1389365373159@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Hasse commented on AS7-1389:
----------------------------------

You seem to be quick to give up a good discussion with an ad hominem attack just when I felt I was going to learn something.  To clarify my comment with respect to "common sense", it specifically referred to limiting classloader visibility, and I think the basic point still stands.  

That said, my motivations are to have the JBoss EAP be the best container it can be to that end I think we should try and put the best case forward from all perspectives.  I'll be honest that I don't really understand your viewpoint very well.  I'll attempt to represent it as best I can and perhaps you can tell me where I've got it incomplete or wrong.  Based on your comments above my impression of your viewpoint is:

JBoss EAP should continue to by default provide classloader visibility of log4j, slf4j and commons logging implementations to JEE application deployments because:

1) That is the way it is currently done in EAP 6.  Also in EAP 5 and 4 default visibility to log4j and commons logging (and later slf4j) were provided.  As a result there are many applications deployed that already use the container-provided logger implementations.  Those applications would need to define an explicit dependency in order to have their logging work properly if the default were changed.
2) 99% of the time users want to have centralized logging (that is, application-level logging interleaved with container logging), and a container-provided logging implementation is the cleanest way to do that.
3) The majority of users who bundle logging implementations with their applications do so by accident and you want to protect those users from their logging being broken by having their application log events written to the server log even if they bundle a logging implementation and corresponding configuration.
4) Packaging a logging implementation and configuration with your application is not portable behavior.  Using container-provided logging implementations is more portable.
5) JBoss EAP is more than just a JEE container.  It provides many additional facilities to JEE applications above and beyond the spec and log4j, slf4j and commons logging implementations are good examples of that sort of value-added functionality.  
6) The spec does not limit what additional facilities can be provided and it is good for container vendors to go above and beyond the JEE specified APIs and their corresponding implementations to provide visibility to additional third-party APIs and implementations by default, specifically in this case third-party logging implementations.
7) It is relatively simple to disable the default visibility and it will be getting even simpler in the future.
8) This is all subjective preference anyway and the reasons for changing are not convincing enough.

Again, my interest is to understand your position as well as I can so if I'm misrepresenting anything or leaving anything out, please do correct me.

Regards,

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Fri Jan 10 09:57:33 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 10 Jan 2014 09:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.38718.1389365853060@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1389:
----------------------------------

I'm not sure #4 is really so black and white, but that's the gist of the reasoning.
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Fri Jan 10 10:03:32 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jan 2014 10:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2736) IronJacamar 1.1.3.Final
In-Reply-To: <JIRA.12529110.1389366189374@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529110.1389366189374@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529110.1389366189374.38725.1389366212972@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2736:
-------------------------------------

             Summary: IronJacamar 1.1.3.Final
                 Key: WFLY-2736
                 URL: https://issues.jboss.org/browse/WFLY-2736
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 8.0.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 issues at jboss.org  Fri Jan 10 10:07:33 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Fri, 10 Jan 2014 10:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.38735.1389366453019@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Hasse commented on AS7-1389:
----------------------------------

Thanks.  So do you feel that within reason and with the caveat above that is the best, most reasonable and complete case we can make for default visibility to the third-party logging implementations?

Regards,

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Fri Jan 10 10:15:34 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 10 Jan 2014 10:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.38767.1389366934499@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1389:
----------------------------------

There is really no such thing as a "complete analysis", but given the constraints of resources, this is what we have, and I think it is more than reasonable enough to stand by.  The fact of our current compatibility requirements really obviates most of the other options in any case.
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Fri Jan 10 10:57:32 2014
From: issues at jboss.org (Stan Zelivinski (JIRA))
Date: Fri, 10 Jan 2014 10:57:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2737) Application that deploys in
 8.0.0.BETA does not deploy in 8.0.0.CR1
In-Reply-To: <JIRA.12529118.1389369416491@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529118.1389369416491@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529118.1389369416491.38900.1389369452961@jira02.app.mwc.hst.phx2.redhat.com>

Stan Zelivinski created WFLY-2737:
-------------------------------------

             Summary: Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
                 Key: WFLY-2737
                 URL: https://issues.jboss.org/browse/WFLY-2737
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: REST
    Affects Versions: 8.0.0.CR1
            Reporter: Stan Zelivinski
            Assignee: Stuart Douglas


We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:

16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field:  [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
	at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
	at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
	at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
	at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
	... 3 more

We are not able to identify the cause for this. Please help.

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

From issues at jboss.org  Fri Jan 10 10:59:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 10 Jan 2014 10:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2737) Application that deploys in
 8.0.0.BETA does not deploy in 8.0.0.CR1
In-Reply-To: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529118.1389369416000.38905.1389369572842@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-2737:
---------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
> -------------------------------------------------------------------
>
>                 Key: WFLY-2737
>                 URL: https://issues.jboss.org/browse/WFLY-2737
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Zelivinski
>            Assignee: Jozef Hartinger
>
> We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
> 16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field:  [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
> 	at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
> 	at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
> 	at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
> 	at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> We are not able to identify the cause for this. Please help.

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

From issues at jboss.org  Fri Jan 10 11:39:32 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 10 Jan 2014 11:39:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2738) Deprecated resource is
 present in r-r-d of /subsystem=security/security-domain=*
In-Reply-To: <JIRA.12529124.1389371915821@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529124.1389371915821@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529124.1389371915821.38964.1389371972723@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2738:
---------------------------------

             Summary: Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
                 Key: WFLY-2738
                 URL: https://issues.jboss.org/browse/WFLY-2738
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Harald Pehl
            Assignee: Kabir Khan
            Priority: Minor


When executing 
{code}
/subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
{code}
the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:

{code}
...
"acl" => {
    "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
    "model-description" => {"classic" => {
        "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
        ...
        "operations" => undefined,
        "children" => {
            "acl-module" => {
                "description" => "ACL module",
                "model-description" => {"*" => {
                    "description" => "List of authentication modules",
                    "operations" => undefined,
                    "children" => {}
                }}
            },
            "login-module" => {
                "description" => "Login module",
                "model-description" => {"*" => undefined}
            }
        }
    }}
},
...
{code}

However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=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 issues at jboss.org  Fri Jan 10 11:41:33 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 10 Jan 2014 11:41:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2738) Deprecated resource is
 present in r-r-d of /subsystem=security/security-domain=*
In-Reply-To: <JIRA.12529124.1389371915000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529124.1389371915000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529124.1389371915000.38973.1389372093392@jira02.app.mwc.hst.phx2.redhat.com>


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

Harald Pehl updated WFLY-2738:
------------------------------

    Description: 
When executing 
{code}
/subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
{code}
the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:

{code}
...
"acl" => {
    "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
    "model-description" => {"classic" => {
        "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
        ...
        "operations" => undefined,
        "children" => {
            "acl-module" => {
                "description" => "ACL module",
                "model-description" => {"*" => {
                    "description" => "List of authentication modules",
                    ...
                    "operations" => undefined,
                    "children" => {}
                }}
            },
            "login-module" => {
                "description" => "Login module",
                "model-description" => {"*" => undefined}
            }
        }
    }}
},
...
{code}

However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}

  was:
When executing 
{code}
/subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
{code}
the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:

{code}
...
"acl" => {
    "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
    "model-description" => {"classic" => {
        "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
        ...
        "operations" => undefined,
        "children" => {
            "acl-module" => {
                "description" => "ACL module",
                "model-description" => {"*" => {
                    "description" => "List of authentication modules",
                    "operations" => undefined,
                    "children" => {}
                }}
            },
            "login-module" => {
                "description" => "Login module",
                "model-description" => {"*" => undefined}
            }
        }
    }}
},
...
{code}

However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}


    
> Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2738
>                 URL: https://issues.jboss.org/browse/WFLY-2738
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Harald Pehl
>            Assignee: Kabir Khan
>            Priority: Minor
>
> When executing 
> {code}
> /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
> {code}
> the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
> {code}
> ...
> "acl" => {
>     "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
>     "model-description" => {"classic" => {
>         "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
>         ...
>         "operations" => undefined,
>         "children" => {
>             "acl-module" => {
>                 "description" => "ACL module",
>                 "model-description" => {"*" => {
>                     "description" => "List of authentication modules",
>                     ...
>                     "operations" => undefined,
>                     "children" => {}
>                 }}
>             },
>             "login-module" => {
>                 "description" => "Login module",
>                 "model-description" => {"*" => undefined}
>             }
>         }
>     }}
> },
> ...
> {code}
> However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=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 issues at jboss.org  Fri Jan 10 11:51:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 10 Jan 2014 11:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1770) Table: null row when removing
	last element
In-Reply-To: <JIRA.12529083.1389355874000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529083.1389355874000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529083.1389355874000.39001.1389372692828@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1770.
----------------------------

    Resolution: Done

    
> Table: null row when removing last element
> ------------------------------------------
>
>                 Key: JGRP-1770
>                 URL: https://issues.jboss.org/browse/JGRP-1770
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
> Note that Table.purge() actually does null entire rows, this is called by
> * NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
> * UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
> The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
> SOLUTION:
> When {{Table.removeMany()}} nulls an element, if that element is tha last element of a row (index = {{elements_per_row -1}}, then null the entire row.
> EFFECT:
> There's less memory held in memory by UNICAST3 receiver 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 issues at jboss.org  Fri Jan 10 11:51:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 10 Jan 2014 11:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB
 messages and message batches
In-Reply-To: <JIRA.12528945.1389266004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528945.1389266004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528945.1389266004000.39005.1389372693015@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1767.
----------------------------

    Resolution: Done

    
> UNICAST3: processing of OOB messages and message batches
> --------------------------------------------------------
>
>                 Key: JGRP-1767
>                 URL: https://issues.jboss.org/browse/JGRP-1767
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Currently, when OOB message batches are received, the following happens:
> * All messages from the batch are added to the table
> * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
> * The batch is passed up
> * Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
> ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
> This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
> * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
> ** Batch
> *** we only add those messages from list L to table T if they haven't yet been added
> *** Messages from L which couldn't be added to T are removed from L
> *** All messages from L are added to a new batch and that batch is then passed up (delivered)
> ** Single message
> *** If the message was added successfuly, we deliver it, else we drop it
> * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
> * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages

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

From issues at jboss.org  Fri Jan 10 11:51:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 10 Jan 2014 11:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.39010.1389372693218@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1717.
----------------------------

    Resolution: Done

    
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, fast.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

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

From issues at jboss.org  Fri Jan 10 11:51:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 10 Jan 2014 11:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1769) Table.add() with message list
 can lead to many resizings
In-Reply-To: <JIRA.12528968.1389267831000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528968.1389267831000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528968.1389267831000.39012.1389372693309@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1769.
----------------------------

    Resolution: Done

    
> Table.add() with message list can lead to many resizings
> --------------------------------------------------------
>
>                 Key: JGRP-1769
>                 URL: https://issues.jboss.org/browse/JGRP-1769
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Table maintains an array of arrays (a matrix) and needs to resize it when adding messages that would go beyond the capacity of the array.
> This is done when adding a message.
> However, when adding a *list of messages*, as we're adding messages individually, we compute the needed capacity and perform a resize if needed.
> This leads to possibly too much copying.
> SOLUTION:
> * When adding a list of messages, do the resizing (if needed) *before* adding messages individually

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

From issues at jboss.org  Fri Jan 10 11:53:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 10 Jan 2014 11:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from
 the internal thread pool should not do work stealing
In-Reply-To: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524440.1383823189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524440.1383823189000.39015.1389372812733@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1732.
----------------------------

    Resolution: Done

    
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1732
>                 URL: https://issues.jboss.org/browse/JGRP-1732
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns

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

From issues at jboss.org  Fri Jan 10 13:10:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Fri, 10 Jan 2014 13:10:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.39113.1389377433206@jira02.app.mwc.hst.phx2.redhat.com>


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

Kyle Lape updated WFLY-2696:
----------------------------

    Steps to Reproduce: 
clean install using domain mode.

batch

{noformat}
/host=master/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
/host=master/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
{noformat}

run-batch

{noformat}
/host=master/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add()
{noformat}

and subsequently try to start an instance. This generates:

{noformat}
17:30:25,066 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
	at java.lang.Enum.valueOf(Enum.java:214) [rt.jar:1.6.0_24]
	at org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.valueOf(SyslogAuditLogHandler.java:315) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createProtocolAddOperation(SyslogAuditLogProtocolResourceDefinition.java:128) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createServerAddOperations(SyslogAuditLogProtocolResourceDefinition.java:107) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogHandlerResourceDefinition.createServerAddOperations(SyslogAuditLogHandlerResourceDefinition.java:105) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.addAuditLog(ManagedServerOperationsFactory.java:444)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.getBootUpdates(ManagedServerOperationsFactory.java:227)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.createBootUpdates(ManagedServerOperationsFactory.java:153)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationStepHandler.execute(ServerToHostProtocolHandler.java:219)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:164) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:303) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.DomainModelControllerService.access$700(DomainModelControllerService.java:140)
	at org.jboss.as.host.controller.DomainModelControllerService$3.joinActiveOperation(DomainModelControllerService.java:515)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationRequestHandler$1.execute(ServerToHostProtocolHandler.java:180)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
	at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
{noformat}


The issue is simple:

{code:java}
package org.jboss.as.domain.management.audit;

public abstract class SyslogAuditLogProtocolResourceDefinition extends SimpleResourceDefinition {
...

    public static ModelNode createProtocolAddOperation(final PathAddress protocolAddress, final ModelNode protocol){
        ModelNode protocolAdd = Util.createAddOperation(protocolAddress);
        protocolAdd.get(HOST.getName()).set(protocol.get(HOST.getName()));
        protocolAdd.get(PORT.getName()).set(protocol.get(PORT.getName()));

        SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}

with:

{noformat}
protocolAddress = (org.jboss.as.controller.PathAddress) [
    ("core-service" => "management"),
    ("access" => "audit"),
    ("syslog-handler" => "mysyslog"),
    ("protocol" => "udp")
]
{noformat}

so "udp" is used... but the enum:

{code:java}
    public enum Transport {
        UDP,
        TCP,
        TLS
    }
{code:java}

has an uppercase UDP.

The same issue happens in

{code:java}
 public static void createServerAddOperations(final List<ModelNode> addOps, final PathAddress protocolAddress, final ModelNode protocol) {
        addOps.add(createProtocolAddOperation(protocolAddress, protocol));

        final SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}

Solution:  make uppercase:

{code:java}
SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue().toUpperCase());
{code}


  was:
clean install using domain mode.

batch
/host=master/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
/host=master/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
run-batch

/host=master/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add()

and subsequently try to start an instance. This generates:

17:30:25,066 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
	at java.lang.Enum.valueOf(Enum.java:214) [rt.jar:1.6.0_24]
	at org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.valueOf(SyslogAuditLogHandler.java:315) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createProtocolAddOperation(SyslogAuditLogProtocolResourceDefinition.java:128) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createServerAddOperations(SyslogAuditLogProtocolResourceDefinition.java:107) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogHandlerResourceDefinition.createServerAddOperations(SyslogAuditLogHandlerResourceDefinition.java:105) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.addAuditLog(ManagedServerOperationsFactory.java:444)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.getBootUpdates(ManagedServerOperationsFactory.java:227)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.createBootUpdates(ManagedServerOperationsFactory.java:153)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationStepHandler.execute(ServerToHostProtocolHandler.java:219)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:164) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:303) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.DomainModelControllerService.access$700(DomainModelControllerService.java:140)
	at org.jboss.as.host.controller.DomainModelControllerService$3.joinActiveOperation(DomainModelControllerService.java:515)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationRequestHandler$1.execute(ServerToHostProtocolHandler.java:180)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
	at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]


The issue is simple:

package org.jboss.as.domain.management.audit;

public abstract class SyslogAuditLogProtocolResourceDefinition extends SimpleResourceDefinition {
...

    public static ModelNode createProtocolAddOperation(final PathAddress protocolAddress, final ModelNode protocol){
        ModelNode protocolAdd = Util.createAddOperation(protocolAddress);
        protocolAdd.get(HOST.getName()).set(protocol.get(HOST.getName()));
        protocolAdd.get(PORT.getName()).set(protocol.get(PORT.getName()));

        SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());

with:

protocolAddress = (org.jboss.as.controller.PathAddress) [
    ("core-service" => "management"),
    ("access" => "audit"),
    ("syslog-handler" => "mysyslog"),
    ("protocol" => "udp")
]

so "udp" is used... but the enum:

    public enum Transport {
        UDP,
        TCP,
        TLS
    }

has an uppercase UDP.

The same issue happens in

 public static void createServerAddOperations(final List<ModelNode> addOps, final PathAddress protocolAddress, final ModelNode protocol) {
        addOps.add(createProtocolAddOperation(protocolAddress, protocol));

        final SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());

Solution:  make uppercase:

SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue().toUpperCase());


    
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Fri Jan 10 13:12:32 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Fri, 10 Jan 2014 13:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.39117.1389377552856@jira02.app.mwc.hst.phx2.redhat.com>


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

Kyle Lape updated WFLY-2696:
----------------------------

    Steps to Reproduce: 
clean install using domain mode.

batch

{noformat}
/host=master/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
/host=master/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
{noformat}

run-batch

{noformat}
/host=master/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add()
{noformat}

and subsequently try to start an instance. This generates:

{noformat}
17:30:25,066 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
	at java.lang.Enum.valueOf(Enum.java:214) [rt.jar:1.6.0_24]
	at org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.valueOf(SyslogAuditLogHandler.java:315) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createProtocolAddOperation(SyslogAuditLogProtocolResourceDefinition.java:128) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createServerAddOperations(SyslogAuditLogProtocolResourceDefinition.java:107) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogHandlerResourceDefinition.createServerAddOperations(SyslogAuditLogHandlerResourceDefinition.java:105) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.addAuditLog(ManagedServerOperationsFactory.java:444)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.getBootUpdates(ManagedServerOperationsFactory.java:227)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.createBootUpdates(ManagedServerOperationsFactory.java:153)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationStepHandler.execute(ServerToHostProtocolHandler.java:219)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:164) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:303) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.DomainModelControllerService.access$700(DomainModelControllerService.java:140)
	at org.jboss.as.host.controller.DomainModelControllerService$3.joinActiveOperation(DomainModelControllerService.java:515)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationRequestHandler$1.execute(ServerToHostProtocolHandler.java:180)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
	at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
{noformat}


The issue is simple:

{code:java}
package org.jboss.as.domain.management.audit;

public abstract class SyslogAuditLogProtocolResourceDefinition extends SimpleResourceDefinition {
...

    public static ModelNode createProtocolAddOperation(final PathAddress protocolAddress, final ModelNode protocol){
        ModelNode protocolAdd = Util.createAddOperation(protocolAddress);
        protocolAdd.get(HOST.getName()).set(protocol.get(HOST.getName()));
        protocolAdd.get(PORT.getName()).set(protocol.get(PORT.getName()));

        SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}

with:

{noformat}
protocolAddress = (org.jboss.as.controller.PathAddress) [
    ("core-service" => "management"),
    ("access" => "audit"),
    ("syslog-handler" => "mysyslog"),
    ("protocol" => "udp")
]
{noformat}

so "udp" is used... but the enum:

{code:java}
    public enum Transport {
        UDP,
        TCP,
        TLS
    }
{code}

has an uppercase UDP.

The same issue happens in

{code:java}
 public static void createServerAddOperations(final List<ModelNode> addOps, final PathAddress protocolAddress, final ModelNode protocol) {
        addOps.add(createProtocolAddOperation(protocolAddress, protocol));

        final SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}

Solution:  make uppercase:

{code:java}
SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue().toUpperCase());
{code}


  was:
clean install using domain mode.

batch

{noformat}
/host=master/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
/host=master/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
{noformat}

run-batch

{noformat}
/host=master/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add()
{noformat}

and subsequently try to start an instance. This generates:

{noformat}
17:30:25,066 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
	at java.lang.Enum.valueOf(Enum.java:214) [rt.jar:1.6.0_24]
	at org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.valueOf(SyslogAuditLogHandler.java:315) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createProtocolAddOperation(SyslogAuditLogProtocolResourceDefinition.java:128) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createServerAddOperations(SyslogAuditLogProtocolResourceDefinition.java:107) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.domain.management.audit.SyslogAuditLogHandlerResourceDefinition.createServerAddOperations(SyslogAuditLogHandlerResourceDefinition.java:105) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.addAuditLog(ManagedServerOperationsFactory.java:444)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.getBootUpdates(ManagedServerOperationsFactory.java:227)
	at org.jboss.as.host.controller.ManagedServerOperationsFactory.createBootUpdates(ManagedServerOperationsFactory.java:153)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationStepHandler.execute(ServerToHostProtocolHandler.java:219)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:164) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:303) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.host.controller.DomainModelControllerService.access$700(DomainModelControllerService.java:140)
	at org.jboss.as.host.controller.DomainModelControllerService$3.joinActiveOperation(DomainModelControllerService.java:515)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationRequestHandler$1.execute(ServerToHostProtocolHandler.java:180)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
	at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
{noformat}


The issue is simple:

{code:java}
package org.jboss.as.domain.management.audit;

public abstract class SyslogAuditLogProtocolResourceDefinition extends SimpleResourceDefinition {
...

    public static ModelNode createProtocolAddOperation(final PathAddress protocolAddress, final ModelNode protocol){
        ModelNode protocolAdd = Util.createAddOperation(protocolAddress);
        protocolAdd.get(HOST.getName()).set(protocol.get(HOST.getName()));
        protocolAdd.get(PORT.getName()).set(protocol.get(PORT.getName()));

        SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}

with:

{noformat}
protocolAddress = (org.jboss.as.controller.PathAddress) [
    ("core-service" => "management"),
    ("access" => "audit"),
    ("syslog-handler" => "mysyslog"),
    ("protocol" => "udp")
]
{noformat}

so "udp" is used... but the enum:

{code:java}
    public enum Transport {
        UDP,
        TCP,
        TLS
    }
{code:java}

has an uppercase UDP.

The same issue happens in

{code:java}
 public static void createServerAddOperations(final List<ModelNode> addOps, final PathAddress protocolAddress, final ModelNode protocol) {
        addOps.add(createProtocolAddOperation(protocolAddress, protocol));

        final SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}

Solution:  make uppercase:

{code:java}
SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue().toUpperCase());
{code}



    
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

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

From issues at jboss.org  Fri Jan 10 14:08:32 2014
From: issues at jboss.org (Eduardo Silva (JIRA))
Date: Fri, 10 Jan 2014 14:08:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2713) ViewExpiredException in
 Chrome on WildFly 8.0.0.CR1
In-Reply-To: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528672.1389025086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528672.1389025086000.39161.1389380912900@jira02.app.mwc.hst.phx2.redhat.com>


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

Eduardo Silva commented on WFLY-2713:
-------------------------------------

I had a different exception, and in several browsers.

An Error Occurred:

/faces/index.xhtml Not Found in ExternalContext as a Resource
- Stack Trace

com.sun.faces.context.FacesFileNotFoundException: /faces/index.xhtml Not Found in ExternalContext as a Resource
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:270)
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:353)
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:246)
	at com.sun.faces.application.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:113)
	at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:241)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
....
                
> ViewExpiredException in Chrome on WildFly 8.0.0.CR1
> ---------------------------------------------------
>
>                 Key: WFLY-2713
>                 URL: https://issues.jboss.org/browse/WFLY-2713
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
> Chrome 31.0.1650.63 @ Fedora 20 x86_64
>            Reporter: Pavol Pitonak
>         Attachments: reproducer.zip
>
>
> # unzip attached reproducer
> # mvn clean package
> # deploy reproducer.war to WildFly 
> # open http://localhost:8080/reproducer/
> # type something to the input
> result:
> * in Chrome, a popup with error is displayed
> * server console contains stack trace:
> {code}
> 17:10:54,852 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (default task-7) javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
> {code}
> * works fine in Firefox 26
> * works fine in WildFly 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 issues at jboss.org  Fri Jan 10 15:08:32 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Fri, 10 Jan 2014 15:08:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2714) EL Comparison don't works in
	attributes
In-Reply-To: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528682.1389035131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528682.1389035131000.39181.1389384512732@jira02.app.mwc.hst.phx2.redhat.com>


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

Ot?vio Garcia commented on WFLY-2714:
-------------------------------------

Thank you Stuart. I'll do a reproducer as soon as possible. Best regards.
                
> EL Comparison don't works in attributes
> ---------------------------------------
>
>                 Key: WFLY-2714
>                 URL: https://issues.jboss.org/browse/WFLY-2714
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> Wildfly 8.0.0 CR1
>            Reporter: Ot?vio Garcia
>            Assignee: Stuart Douglas
>              Labels: el, wildfly
>
> I have a class with BigDecimal attribute:
> {code:java}
> public class Foo {
>     private BigDecimal value;
> }
> {code}
> This code works fine
> {code:xml}
> <p>${foo.value lt 0}</p>
> {code}
> And this code too:
> {code:xml}
> <p>${foo.value lt 0 ? 'negative' : 'positive'}</p>
> {code}
> But when I use the expression in the attribute, I get the errot bellow:
> {code:xml}
> <p class="${foo.value lt 0 ? 'negative' : 'positive'}">text</p>
> {code}
> The class 'Foo' does not have the property 'valuelt0'.

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


From issues at jboss.org  Fri Jan 10 15:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 15:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.39197.1389385953194@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1029687|https://bugzilla.redhat.com/show_bug.cgi?id=1029687] from POST to MODIFIED
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Fri Jan 10 15:34:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 15:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.39200.1389386072759@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1049999|https://bugzilla.redhat.com/show_bug.cgi?id=1049999] from POST to MODIFIED
                
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Fri Jan 10 15:56:33 2014
From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=)
Date: Fri, 10 Jan 2014 15:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358917@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358917@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358917.39209.1389387393014@jira02.app.mwc.hst.phx2.redhat.com>

P?tr Andreev created WFLY-2739:
----------------------------------

             Summary: BeanDeploymentArchive for external (WFLY) modules added twice
                 Key: WFLY-2739
                 URL: https://issues.jboss.org/browse/WFLY-2739
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
         Environment: Win7,CentOS6
            Reporter: P?tr Andreev
            Assignee: Stuart Douglas


The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

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


From issues at jboss.org  Fri Jan 10 16:12:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 10 Jan 2014 16:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2740) Support timeout of management
	operations
In-Reply-To: <JIRA.12529136.1389388347311@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529136.1389388347311@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529136.1389388347311.39219.1389388352701@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2740:
--------------------------------------

             Summary: Support timeout of management operations
                 Key: WFLY-2740
                 URL: https://issues.jboss.org/browse/WFLY-2740
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


There have been various situations where bugs in WF or in user code have prevented management operations from completing, leaving the ModelController locked permanently, unless the process is stopped. There should be mechanism via which timeouts can be set.

My proposal is to allow a timeout to be set via a management operation header. In addition, there will be a standard timeout that will apply if no header is present.

The standard timeout will be quite lengthy, probably several minutes. The goal is to allow a management process to eventually auto-recover, not to do prompt detection of failures. Users can use the header if they wish prompt detection a failures. A short standard timeout runs the risk of false positives, particularly with large deployments.

The meaning of this timeout is not to be an overall maximum time for operation execution. There would be no valid default for such a timeout in a managed domain, where the time it would take to roll out a change would depend on the size of the domain and the rollout plan.

Rather, this timeout is meant to be the maximum period operation execution threads can block in various points. Blocking for longer than the timeout would result in operation 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 issues at jboss.org  Fri Jan 10 16:18:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 10 Jan 2014 16:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2741) Single process management
 operation timeouts
In-Reply-To: <JIRA.12529137.1389388594796@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529137.1389388594796@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529137.1389388594796.39221.1389388712680@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2741:
--------------------------------------

             Summary: Single process management operation timeouts
                 Key: WFLY-2741
                 URL: https://issues.jboss.org/browse/WFLY-2741
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 9.0.0.CR1


Portion of the parent task related to operation execution within a single process (i.e. not involving intra-process calls in a domain).

Potential points to apply the timeout:

ModelControllerImpl.acquireLock() 

Questionable, as blocking here means waiting for another op, not a problem with the current op

ModelControllerImpl.awaitContainerMonitor() -> ContainerStateMonitor.await() -> StabilityMonitor.awaitStability()

This is the typical blocking point in a server op
-- on way in, fail the op
-- on way out (OperationContextImpl.releaseStepLocks()) log a WARN/ERROR

ModelControllerImpl.awaitContainerStateChangedReport()
-- on the way in, before VERIFY

OperationContextImpl.waitForRemovals()
-- on way in, before VERIFY
-- on way out, in handleRollback
---- problem: this is called repeatedly

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

From issues at jboss.org  Fri Jan 10 16:18:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 10 Jan 2014 16:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2740) Support timeout of management
	operations
In-Reply-To: <JIRA.12529136.1389388347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529136.1389388347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529136.1389388347000.39222.1389388712721@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2740:
-----------------------------------

    Fix Version/s: 9.0.0.CR1

    
> Support timeout of management operations
> ----------------------------------------
>
>                 Key: WFLY-2740
>                 URL: https://issues.jboss.org/browse/WFLY-2740
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 9.0.0.CR1
>
>
> There have been various situations where bugs in WF or in user code have prevented management operations from completing, leaving the ModelController locked permanently, unless the process is stopped. There should be mechanism via which timeouts can be set.
> My proposal is to allow a timeout to be set via a management operation header. In addition, there will be a standard timeout that will apply if no header is present.
> The standard timeout will be quite lengthy, probably several minutes. The goal is to allow a management process to eventually auto-recover, not to do prompt detection of failures. Users can use the header if they wish prompt detection a failures. A short standard timeout runs the risk of false positives, particularly with large deployments.
> The meaning of this timeout is not to be an overall maximum time for operation execution. There would be no valid default for such a timeout in a managed domain, where the time it would take to roll out a change would depend on the size of the domain and the rollout plan.
> Rather, this timeout is meant to be the maximum period operation execution threads can block in various points. Blocking for longer than the timeout would result in operation 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 issues at jboss.org  Fri Jan 10 16:22:33 2014
From: issues at jboss.org (Dickon Field (JIRA))
Date: Fri, 10 Jan 2014 16:22:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-741) Support recovery scenarios
In-Reply-To: <JIRA.12393043.1251730810000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12393043.1251730810000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12393043.1251730810000.39232.1389388953985@jira02.app.mwc.hst.phx2.redhat.com>


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

Dickon Field commented on WFLY-741:
-----------------------------------

What is the context around this issue? Does this relate to older versions of JBoss, or is this an issue for WildFly 8?
                
> Support recovery scenarios
> --------------------------
>
>                 Key: WFLY-741
>                 URL: https://issues.jboss.org/browse/WFLY-741
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Jesper Pedersen
>              Labels: community_contribution
>             Fix For: Awaiting Volunteers
>
>
> This is a container task for adding recovery support into the AS.

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

From issues at jboss.org  Fri Jan 10 16:26:32 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 10 Jan 2014 16:26:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2742) Domain rollout operation
	timeouts
In-Reply-To: <JIRA.12529138.1389389097319@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529138.1389389097319@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529138.1389389097319.39237.1389389192663@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2742:
--------------------------------------

             Summary: Domain rollout operation timeouts
                 Key: WFLY-2742
                 URL: https://issues.jboss.org/browse/WFLY-2742
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 9.0.0.CR1


Portion of the parent task related to rolling out changes to a domain.

The expectation is that single process timeouts (WFLY-2741) will handle most failure conditions related to domain rollouts (e.g. if a single server hangs, preventing completion of the rollout, eventually that server will time out, allowing the domain wide rollout to continue.) Timeouts in the domain rollout code serve as a second line of defense:

1) In case of protocol or other problems that prevent the calling process learning about the timeout on the remote process
2) In case of bugs in the single process timeout handling on the remote process
3) In mixed domain cases where remote hosts are running previous versions and do not have the timeout function

Potential places to add timeouts:

DomainSlaveHandler->HostControllerUpdateTask.ProxyOperationListener.retrievePreparedOperation()
-- where the master HC waits for responses from slaves

RollingServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
-- timeout here means 1 server didn't respond, but need to move on to next

ConcurrentServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
-- timeout here means none of the remaining servers have responded w/in the timeout

DomainRolloutStepHandler.finalizeOp() -> future.get()
---- the ServerGroupUpdateTask should fail in the normal phase, so any timeout here would indicate a problem committing the tx or a comms problem getting back the 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 issues at jboss.org  Fri Jan 10 18:02:32 2014
From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=)
Date: Fri, 10 Jan 2014 18:02:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.39255.1389394952804@jira02.app.mwc.hst.phx2.redhat.com>


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

P?tr Andreev updated WFLY-2739:
-------------------------------

    Workaround Description: 
exclude already processed beans.xml:
https://github.com/petrandreev/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java#L175-176
                Workaround: Workaround Exists

    
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Stuart Douglas
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

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


From issues at jboss.org  Fri Jan 10 18:02:32 2014
From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=)
Date: Fri, 10 Jan 2014 18:02:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.39257.1389394952921@jira02.app.mwc.hst.phx2.redhat.com>


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

P?tr Andreev updated WFLY-2739:
-------------------------------

    Workaround Description: 
exclude already processed beans.xml:
https://github.com/petrandreev/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java#L175-176

pull request can be provided

  was:
exclude already processed beans.xml:
https://github.com/petrandreev/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java#L175-176


    
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Stuart Douglas
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

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


From issues at jboss.org  Fri Jan 10 18:54:32 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Fri, 10 Jan 2014 18:54:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot
 find custom ldap socket factory
In-Reply-To: <JIRA.12529141.1389397970315@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529141.1389397970315@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529141.1389397970315.39297.1389398072739@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created SECURITY-784:
-------------------------------------

             Summary: LdapExtLoginModule cannot find custom ldap socket factory
                 Key: SECURITY-784
                 URL: https://issues.jboss.org/browse/SECURITY-784
             Project: PicketBox 
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PicketBox
    Affects Versions: PicketBox_4_0_19.Final
            Reporter: Derek Horton
            Assignee: Stefan Guilhen


LdapExtLoginModule cannot find custom ldap socket factory.

Passing the  "java.naming.ldap.factory.socket" property in as an
module-option:

  <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>

results in a ClassNotFoundException:

Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
     at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
     at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
     at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
     at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
     at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
     at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
     at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]

I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
sun.jdk.  Unfortunately, that did not work.  I also added the socket
factory jar to the jre/lib/ext directory.  That didn't work either.


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

From issues at jboss.org  Fri Jan 10 19:46:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 19:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.39305.1389401193753@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 976917|https://bugzilla.redhat.com/show_bug.cgi?id=976917] from ASSIGNED to POST
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

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

From issues at jboss.org  Fri Jan 10 19:46:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 10 Jan 2014 19:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.39308.1389401193864@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1051189|https://bugzilla.redhat.com/show_bug.cgi?id=1051189] from NEW to POST
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

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

From issues at jboss.org  Sat Jan 11 03:20:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sat, 11 Jan 2014 03:20:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2743) Some static references are
 stored to the ServiceRegistry that do not have permission checks
In-Reply-To: <JIRA.12529147.1389428365204@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529147.1389428365204@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529147.1389428365204.39340.1389428432718@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2743:
------------------------------------

             Summary: Some static references are stored to the ServiceRegistry that do not have permission checks
                 Key: WFLY-2743
                 URL: https://issues.jboss.org/browse/WFLY-2743
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Stuart Douglas


This enables a deployment to get access to the MSC ServiceRegistry, and from there change internal server state without any security manager checks. 

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

From issues at jboss.org  Sat Jan 11 03:48:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 11 Jan 2014 03:48:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2743) Some static references are
 stored to the ServiceRegistry that do not have permission checks
In-Reply-To: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529147.1389428365000.39343.1389430112884@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2743:
------------------------------------------

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

    
> Some static references are stored to the ServiceRegistry that do not have permission checks
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2743
>                 URL: https://issues.jboss.org/browse/WFLY-2743
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stuart Douglas
>
> This enables a deployment to get access to the MSC ServiceRegistry, and from there change internal server state without any security manager checks. 

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

From issues at jboss.org  Sat Jan 11 11:16:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 11 Jan 2014 11:16:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.39386.1389456994702@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1050003|https://bugzilla.redhat.com/show_bug.cgi?id=1050003] from POST to MODIFIED
                
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Sat Jan 11 15:25:33 2014
From: issues at jboss.org (Leos Literak (JIRA))
Date: Sat, 11 Jan 2014 15:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2744) JPA .schema-generation-action
 compliance issue
In-Reply-To: <JIRA.12529153.1389471913092@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529153.1389471913092@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529153.1389471913092.39424.1389471933173@jira02.app.mwc.hst.phx2.redhat.com>

Leos Literak created WFLY-2744:
----------------------------------

             Summary: JPA .schema-generation-action compliance issue
                 Key: WFLY-2744
                 URL: https://issues.jboss.org/browse/WFLY-2744
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.CR1
         Environment: windows
            Reporter: Leos Literak
            Assignee: Scott Marlow


I had following persistence.xml in my war application:

<?xml version="1.0" encoding="UTF-8"?>
<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://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="OAUTHDEMO" transaction-type="JTA">
    <jta-data-source>java:jboss/datasources/test</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
        <property name="javax.persistence.schema-generation.database.action" value="create"/>
    </properties>
  </persistence-unit>
</persistence>

When I ran it second time, deployment failed because table already existed. I downloaded JPA specification to read how it is defined and there is such statement:

javax.persistence.schema-generation-action
The javax.persistence.schema-generation-action property specifies the
action to be taken by the persistence provider. If the javax.persistence.
schema-generation-target property is not specified, no action must be
taken, regardless of the value of the javax.persistence.schema-generation-
action property. The values for this property are "none", "create",
"drop-and-create", "drop".

Following sentence is interesting, because I do not have the schema-generation-target property defined:

If the javax.persistence.
schema-generation-target property is not specified, no action must be
taken, regardless of the value of the javax.persistence.schema-generation-action property. 

So unless I misunderstood this line, then JPA implementation is incorrect.

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

From issues at jboss.org  Sun Jan 12 05:12:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 12 Jan 2014 05:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.39454.1389521552989@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from POST to MODIFIED
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

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

From issues at jboss.org  Sun Jan 12 05:14:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 12 Jan 2014 05:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.39457.1389521672869@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1029099|https://bugzilla.redhat.com/show_bug.cgi?id=1029099] from POST to MODIFIED
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Sun Jan 12 05:14:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 12 Jan 2014 05:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2697) Domain Mode does not start
 with the IBM JDK
In-Reply-To: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528491.1388497046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528491.1388497046000.39460.1389521673056@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1047515|https://bugzilla.redhat.com/show_bug.cgi?id=1047515] from POST to MODIFIED
                
> Domain Mode does not start with the IBM JDK
> -------------------------------------------
>
>                 Key: WFLY-2697
>                 URL: https://issues.jboss.org/browse/WFLY-2697
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows (OS), IBM JDK 7
>            Reporter: Eric Rich
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> When starting domain mode with the IBM JDK the following is produced 3 out of 4 times. 
> [Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
> [Host Controller]     ("host" => "master"),
> [Host Controller]     ("server-config" => "server-one")
> [Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
> [Host Controller]       at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)
> [Host Controller]       at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:781)
> [Host Controller]       at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:107)
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282)
> [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jbo
> ss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-contr
> oller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.
> 3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(Mode
> lControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(Mod
> elControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelC
> ontrollerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.security.AccessController.doPrivileged(AccessController.java:366) [vm.jar:1.7.0]
> [Host Controller]       at javax.security.auth.Subject.doAs(Subject.java:572) [rt.jar:1.7.0]
> [Host Controller]       at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Fi
> nal-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(Mode
> lControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-a
> s-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [j
> boss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) [rt.jar:1.7.0]
> [Host Controller]       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) [rt.jar:1.7.0]
> [Host Controller]       at java.lang.Thread.run(Thread.java:804) [vm.jar:1.7.0]
> [Host Controller]       at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Fin
> al-redhat-1]
> [Host Controller]

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

From issues at jboss.org  Sun Jan 12 05:14:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 12 Jan 2014 05:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-898)
	SharedLocalYieldingLockManager.LocalLock
In-Reply-To: <JIRA.12479431.1353286224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479431.1353286224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479431.1353286224000.39473.1389521673691@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from POST to MODIFIED
                
> SharedLocalYieldingLockManager.LocalLock
> ----------------------------------------
>
>                 Key: WFLY-898
>                 URL: https://issues.jboss.org/browse/WFLY-898
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: MJ Kim
>            Assignee: Paul Ferraro
>
> Hi,
>  
> Recently my system has been in the QA. (includes Stress test, Endurance test)
> During the endurance test, I found that the heap space was getting exausted, and not removed after full gc.
> When the heap space got close to 90%, the gabage collection was happend every 2 min, and my system was stopped reponding.
> The heap space was not cleaned up, nevertheless I ended the test (no request during a few hours)
>  
>  
> I downloaded some heap dumps, and found that the SharedLocalYieldingLockManage.LocalLock() resided much of heap space. (above 60%)
> I think the session expiration doesn't operate porperly.
>  
> If the SessionBasesClusteredSession class raises the expiration signals with "LocalOnly=True", the lock would not be removed.
>  
> Addionally, I reviewed our source code and did a leakage discory test, anything was matter.
>  
> Here is my environment. If you want to see my standalone.xml, please post a reply thread.
>  
> <Cluster>
> - 8 JVM (4 machine, each 2)
> - JDK : 1.6u31
> - OS : Amazon Linux 64bit
> - JGroups : FILE_PING (The shared storage is GlusterFS volume)
> - Infinispan operation mode : L1 + Distribution / ASYNC / expiration 1min
> - Session handling : web.xml (expiration every 1min)
>    (Originally our setting was 30 min. Beacuse the load generator was sending too many requests with new session, I lowered the threshold to 1min)
> - Source code : 7.1.3 Final tag (downloaded from Github)

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

From issues at jboss.org  Sun Jan 12 05:14:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 12 Jan 2014 05:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-406) Redesign web session clustering
In-Reply-To: <JIRA.12489848.1366310318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489848.1366310318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489848.1366310318000.39476.1389521673811@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1039585|https://bugzilla.redhat.com/show_bug.cgi?id=1039585] from POST to MODIFIED
                
> Redesign web session clustering
> -------------------------------
>
>                 Key: WFLY-406
>                 URL: https://issues.jboss.org/browse/WFLY-406
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha2
>
>
> The current web session replication code has been around for ages and suffers from a number of issues:
> * By maintaining a separate local map of sessions in conjunction with the session data stored in the distributed cache, stale data is inevitable - a number of issues have cropped up in EAP testing.
> * Extra concurrency measures are required to ensure synchronicity of the local session map with the distributed cache.
> * Extra logic/locking is required to invalidate the local session map is required per request
> * AtomicMaps, on which the current implementation relies, have proven buggy
> * Session access outside of the scope of the replication valve is possible and problematic
> * Maintaining sessions locally means that the clustering code needs to implement passivation and expiration manually - instead of leveraging Infinispan full capabilities.
> * The current code base is tightly coupled to JBoss Web.  Migrating the code to support Undertow will inevitably introduce issues and code duplication.
> The new design will incorporate a proper SPI for the servlet container.  Thus the logic to integrate with Undertow vs JBoss Web will be relatively thin.

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

From issues at jboss.org  Sun Jan 12 08:27:32 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Sun, 12 Jan 2014 08:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2734) Unable to use --runtime_name
 in jboss-cli deploy command
In-Reply-To: <JIRA.12529045.1389308716000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529045.1389308716000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529045.1389308716000.39523.1389533252790@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins closed WFLY-2734.
-------------------------------

    Resolution: Duplicate Issue


Original issue AS7-4622
                
> Unable to use --runtime_name in jboss-cli deploy command
> --------------------------------------------------------
>
>                 Key: WFLY-2734
>                 URL: https://issues.jboss.org/browse/WFLY-2734
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Running on Windows 7
>            Reporter: David Hatten
>              Labels: jboss, jboss-as
>
> When using the jboss-cli utility, I am unable to use the --runtime_name parameter to specify a Runtime Name. I have tried the following configurations:
> 1) Deploy a war using both --name and --runtime_name. When I view the deployment in the admin console, both the Name and Runtime Name fields are set to the value of --name
> 2) Deploy a war using only --runtime_name parameter. When I view the deployment in the admin console, the Runtime Name is the name of the file being deployed.
> In both cases, the specified value of --runtime_name is ignored. I believe this is a bug and not a configuration 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 issues at jboss.org  Sun Jan 12 11:35:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 12 Jan 2014 11:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2743) Some static references are
 stored to the ServiceRegistry that do not have permission checks
In-Reply-To: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529147.1389428365000.39542.1389544532842@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2743:
------------------------------------

    Assignee: Stuart Douglas

    
> Some static references are stored to the ServiceRegistry that do not have permission checks
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2743
>                 URL: https://issues.jboss.org/browse/WFLY-2743
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This enables a deployment to get access to the MSC ServiceRegistry, and from there change internal server state without any security manager checks. 

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

From issues at jboss.org  Sun Jan 12 16:51:32 2014
From: issues at jboss.org (Arun Gupta (JIRA))
Date: Sun, 12 Jan 2014 16:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2745) Typo in jboss-cli help message
In-Reply-To: <JIRA.12529155.1389563386785@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529155.1389563386785@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529155.1389563386785.39575.1389563492851@jira02.app.mwc.hst.phx2.redhat.com>

Arun Gupta created WFLY-2745:
--------------------------------

             Summary: Typo in jboss-cli help message
                 Key: WFLY-2745
                 URL: https://issues.jboss.org/browse/WFLY-2745
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: 8.0.0.CR1
            Reporter: Arun Gupta
            Assignee: Alexey Loubyansky
            Priority: Trivial


jboss-cli -h shows the following help message for --controller.

The default controller host is localhost and the port is 9999.

The port number should be 9990 instead of 9999.

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

From issues at jboss.org  Sun Jan 12 18:14:32 2014
From: issues at jboss.org (Richard Kennard (JIRA))
Date: Sun, 12 Jan 2014 18:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-888) f:validateBean disabled="true"
 is lost following POST-back
In-Reply-To: <JIRA.12458342.1328393976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458342.1328393976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458342.1328393976000.39584.1389568472974@jira02.app.mwc.hst.phx2.redhat.com>


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

Richard Kennard commented on WFLY-888:
--------------------------------------

FYI: apparently http://java.net/jira/browse/JAVASERVERFACES-2526 has now been resolved.
                
> f:validateBean disabled="true" is lost following POST-back
> ----------------------------------------------------------
>
>                 Key: WFLY-888
>                 URL: https://issues.jboss.org/browse/WFLY-888
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>            Reporter: Richard Kennard
>            Assignee: Stan Silvert
>
> As discussed on FORGE-460:
> Richard: "I think an 'easy default' would be to just add <f:validateBean disabled="#{true}"/> to each search field. However this doesn't appear to survive POST-back (i.e. it works for one click, but then fails after that). Are you aware of this? Is it a bug? I attach a minimal test case. I'd be most grateful if you could look at it".
> Emmanuel: "Yes that's definitely a bug. I'd bet in the JSF engine".
> Pete: "Richard, could you open an AS7 bug. Assign it to Stan (or if you can't assign, ask me to)".
> Minimal test case attached to FORGE-460: https://issues.jboss.org/secure/attachment/12351185/emmanuel.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 issues at jboss.org  Sun Jan 12 18:16:33 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Sun, 12 Jan 2014 18:16:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.39588.1389568593949@jira02.app.mwc.hst.phx2.redhat.com>


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

Max Rydahl Andersen commented on WFLY-2729:
-------------------------------------------

[~ctomc] "clean server" should be the same as removing the deployement with rm on command line.

My guess is this is dependent on the application and does not require the tools to reproduce.



                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Max Rydahl Andersen
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Sun Jan 12 18:16:34 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Sun, 12 Jan 2014 18:16:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.39591.1389568594061@jira02.app.mwc.hst.phx2.redhat.com>


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

Max Rydahl Andersen updated WFLY-2729:
--------------------------------------

    Assignee: Tomaz Cerar  (was: Max Rydahl Andersen)

    
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Sun Jan 12 23:27:32 2014
From: issues at jboss.org (Paa Kojo Konduah Amos (JIRA))
Date: Sun, 12 Jan 2014 23:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.39777.1389587252828@jira02.app.mwc.hst.phx2.redhat.com>


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

Paa Kojo Konduah Amos commented on WFLY-2729:
---------------------------------------------

So, am i gtting the sense that, this issue is coming from JBoss Tools?...Personally i really dont like switching spaces at development time just to do 'clean server'. So do i file another issue @ JBoss Tools?
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Sun Jan 12 23:35:32 2014
From: issues at jboss.org (Paa Kojo Konduah Amos (JIRA))
Date: Sun, 12 Jan 2014 23:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.39784.1389587732776@jira02.app.mwc.hst.phx2.redhat.com>


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

Paa Kojo Konduah Amos commented on WFLY-2729:
---------------------------------------------

please is there a way to share this with them(JBoss Tools).?
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Mon Jan 13 03:20:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 13 Jan 2014 03:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2737) Application that deploys in
 8.0.0.BETA does not deploy in 8.0.0.CR1
In-Reply-To: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529118.1389369416000.39873.1389601233088@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2737:
---------------------------------------

Does your application bundles RESTEasy jars? Are you able to create a minimal application that reproduces the issue?
                
> Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
> -------------------------------------------------------------------
>
>                 Key: WFLY-2737
>                 URL: https://issues.jboss.org/browse/WFLY-2737
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Zelivinski
>            Assignee: Jozef Hartinger
>
> We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
> 16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field:  [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
> 	at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
> 	at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
> 	at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
> 	at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> We are not able to identify the cause for this. Please help.

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

From issues at jboss.org  Mon Jan 13 03:34:32 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 13 Jan 2014 03:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.39884.1389602072991@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-2729:
-----------------------------------

Paa, Max is tools lead and  has already checked this.

What you are getting is mostly a warning and it is save to ignore.
There is already discussion about this here https://community.jboss.org/message/852481

In short in CR1 we added option to enable persistent sessions between redeploys which helps development lifecycle.
It is a new feature and as such has few bugs :-) but that is a warning and not error and it is safe to ignore, it just tells you that it was unable to reload session after redeploy. 
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Mon Jan 13 04:24:32 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 13 Jan 2014 04:24:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.40010.1389605072841@jira02.app.mwc.hst.phx2.redhat.com>


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

Max Rydahl Andersen commented on WFLY-2729:
-------------------------------------------

[~pkkamos] just to be clear - this is not limited to tools. It would happen for any redeployments because of the new persistent session feature.

[~ctomc] is there a jira to make the error handling around persistent sessions less noisy ? i.e. its interesting to know persistent sessions didn't complete but getting a full stacktrace everytime seems overkill?

                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Mon Jan 13 04:52:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 13 Jan 2014 04:52:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2450) JSF managed classes do not
 support CDI interception
In-Reply-To: <JIRA.12518163.1383753817000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518163.1383753817000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518163.1383753817000.40041.1389606753200@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2450:
---------------------------------------

Depends on https://java.net/jira/browse/JAVASERVERFACES-3142
                
> JSF managed classes do not support CDI interception
> ---------------------------------------------------
>
>                 Key: WFLY-2450
>                 URL: https://issues.jboss.org/browse/WFLY-2450
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>
> Testcase:
> https://github.com/mkouba/wildfly/commit/a9698d163da159dcbbf27da0679cf35c1ba0be87

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

From issues at jboss.org  Mon Jan 13 05:00:34 2014
From: issues at jboss.org (Ludger Brinkmann (JIRA))
Date: Mon, 13 Jan 2014 05:00:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2686) Missing dependency in
 com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider
In-Reply-To: <JIRA.12528399.1387879706000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528399.1387879706000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528399.1387879706000.40052.1389607234751@jira02.app.mwc.hst.phx2.redhat.com>


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

Ludger Brinkmann updated WFLY-2686:
-----------------------------------

    Description: 
Dependency javax.xml.bind.api is missing in module.xml of com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider.

For a detailed description, see https://community.jboss.org/thread/233865

As a workaround, the  module.xml can either be changed manually or the resteasy-jboss-modules-wf8-3.0.6.Final.zip provided with the RESTEasy distribution may be unzipped in the modules/system/layers/base directory.

Correct dependencies should look like:

    <dependencies>
        <module name="javax.api"/>
        <module name="javax.ws.rs.api"/>
        <module name="javax.xml.bind.api"/>
        <module name="com.fasterxml.jackson.core.jackson-annotations"/>
        <module name="com.fasterxml.jackson.core.jackson-core"/>
        <module name="com.fasterxml.jackson.core.jackson-databind"/>
    </dependencies>


  was:
Dependency javax.xml.bind.api is missing in module.xml of com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider.

For a detailed description, see https://community.jboss.org/thread/233865

As a workaround, the  module.xml can either be changed manually or the resteasy-jboss-modules-wf8-3.0.6.Final.zip provided with the RESTEasy distribution may be unzipped in the modules/system/layers/base directory.

    Component/s: REST

    
> Missing dependency in com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2686
>                 URL: https://issues.jboss.org/browse/WFLY-2686
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, REST
>    Affects Versions: 8.0.0.Beta1, 8.0.0.CR1
>            Reporter: Ludger Brinkmann
>
> Dependency javax.xml.bind.api is missing in module.xml of com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider.
> For a detailed description, see https://community.jboss.org/thread/233865
> As a workaround, the  module.xml can either be changed manually or the resteasy-jboss-modules-wf8-3.0.6.Final.zip provided with the RESTEasy distribution may be unzipped in the modules/system/layers/base directory.
> Correct dependencies should look like:
>     <dependencies>
>         <module name="javax.api"/>
>         <module name="javax.ws.rs.api"/>
>         <module name="javax.xml.bind.api"/>
>         <module name="com.fasterxml.jackson.core.jackson-annotations"/>
>         <module name="com.fasterxml.jackson.core.jackson-core"/>
>         <module name="com.fasterxml.jackson.core.jackson-databind"/>
>     </dependencies>

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

From issues at jboss.org  Mon Jan 13 05:14:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 13 Jan 2014 05:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2686) Missing dependency in
 com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider
In-Reply-To: <JIRA.12528399.1387879706000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528399.1387879706000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528399.1387879706000.40088.1389608072770@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-2686:
------------------------------------

    Assignee: Stuart Douglas

    
> Missing dependency in com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2686
>                 URL: https://issues.jboss.org/browse/WFLY-2686
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, REST
>    Affects Versions: 8.0.0.Beta1, 8.0.0.CR1
>            Reporter: Ludger Brinkmann
>            Assignee: Stuart Douglas
>
> Dependency javax.xml.bind.api is missing in module.xml of com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider.
> For a detailed description, see https://community.jboss.org/thread/233865
> As a workaround, the  module.xml can either be changed manually or the resteasy-jboss-modules-wf8-3.0.6.Final.zip provided with the RESTEasy distribution may be unzipped in the modules/system/layers/base directory.
> Correct dependencies should look like:
>     <dependencies>
>         <module name="javax.api"/>
>         <module name="javax.ws.rs.api"/>
>         <module name="javax.xml.bind.api"/>
>         <module name="com.fasterxml.jackson.core.jackson-annotations"/>
>         <module name="com.fasterxml.jackson.core.jackson-core"/>
>         <module name="com.fasterxml.jackson.core.jackson-databind"/>
>     </dependencies>

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

From issues at jboss.org  Mon Jan 13 05:20:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 13 Jan 2014 05:20:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2562) Install mod_cluster service
	as ACTIVE
In-Reply-To: <JIRA.12525997.1385327374000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525997.1385327374000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525997.1385327374000.40103.1389608432844@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar updated WFLY-2562:
---------------------------------

        Summary: Install mod_cluster service as ACTIVE  (was: mod_cluster service should have required dependency on listener)
    Description: This is result of workarounding dependency scheme to support JBW and Undertow at the same time. Since we only support Undertow at the moment, the service should be installed as ACTIVE instead of PASSIVE.  (was: This is result of workarounding dependency scheme to support JBW and UT at the same time.)

    
> Install mod_cluster service as ACTIVE
> -------------------------------------
>
>                 Key: WFLY-2562
>                 URL: https://issues.jboss.org/browse/WFLY-2562
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> This is result of workarounding dependency scheme to support JBW and Undertow at the same time. Since we only support Undertow at the moment, the service should be installed as ACTIVE instead of PASSIVE.

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

From issues at jboss.org  Mon Jan 13 05:30:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 13 Jan 2014 05:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2722) @EJB injection in interceptor
 class and in target class result in injection of instances of two different
 classes
In-Reply-To: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528310.1387545321000.40127.1389609033083@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2722.
----------------------------------

    Resolution: Rejected


The current behaviour is fine. 

@EJB does not do a look up, instead it resolves the EJB and then binds it to the naming context. In effect there will be two entries bound to the shared naming context:

java:comp/env/com....Bar/animal
java:comp/env/com....BarInterceptor/animal

The actual EJB that is resolved depends on the packaged location. I know this is not super intuitive, but it is what the spec requires.
                
> @EJB injection in interceptor class and in target class result in injection of instances of two different classes
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2722
>                 URL: https://issues.jboss.org/browse/WFLY-2722
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Matus Abaffy
>            Assignee: Jozef Hartinger
>
> Interceptors spec, 2.2.1 - Interceptor Environment:
> bq. Interceptor class shares the enterprise naming context of its associated target class. (1)
> Assume the following scenario:
> Ear: test-ejb.jar, test1.war, test2.war
>   test-ejb.jar: Animal, BarBinding
>   test1.war: BarInterceptor, Dog
>   test2.war: Bar, Cat
> Short description of the classes:
> {code}
> @Stateful public class Dog implements Animal {...}
> {code}
> {code}
> @Stateful public class Cat implements Animal {...}
> {code}
> {code}
> @BarBinding @Stateless
> public class Bar {
>     @EJB
>     Animal animal;
> }
> {code}
> {code}
> @BarBinding @Priority(1000) @Interceptor
> public class BarInterceptor {
>     @EJB
>     Animal animal;
> }
> {code}
> Bar gets injected an instance of Cat, whereas BarInterceptor gets injected an instance of Dog, which IMHO contradicts (1).
> Test case at: https://github.com/cdi-spec/cdi-tck/pull/38
> (InterceptorEnvironmentJNDITest, InterceptorEnvironmentJNDISessionBeanTest)

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

From issues at jboss.org  Mon Jan 13 05:48:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Jan 2014 05:48:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106096@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106096@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106096.40149.1389610112823@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2746:
--------------------------------

             Summary: Workaround for auditlog syslog Facility not being configurable
                 Key: WFLY-2746
                 URL: https://issues.jboss.org/browse/WFLY-2746
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.Final


Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

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

From issues at jboss.org  Mon Jan 13 05:50:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Jan 2014 05:50:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2747) Make auditlog syslog facility
	configurable
In-Reply-To: <JIRA.12529186.1389610201786@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529186.1389610201786@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529186.1389610201786.40152.1389610232791@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2747:
--------------------------------

             Summary: Make auditlog syslog facility configurable
                 Key: WFLY-2747
                 URL: https://issues.jboss.org/browse/WFLY-2747
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.Final


Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch

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

From issues at jboss.org  Mon Jan 13 05:52:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Jan 2014 05:52:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2747) Make auditlog syslog facility
	configurable
In-Reply-To: <JIRA.12529186.1389610201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529186.1389610201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529186.1389610201000.40156.1389610352693@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated WFLY-2747:
-----------------------------

    Description: Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch. Once done the workaround in WFLY-2746 should be removed  (was: Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch)

    
> Make auditlog syslog facility configurable
> ------------------------------------------
>
>                 Key: WFLY-2747
>                 URL: https://issues.jboss.org/browse/WFLY-2747
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch. Once done the workaround in WFLY-2746 should 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 issues at jboss.org  Mon Jan 13 06:02:32 2014
From: issues at jboss.org (Matus Abaffy (JIRA))
Date: Mon, 13 Jan 2014 06:02:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2722) @EJB injection in interceptor
 class and in target class result in injection of instances of two different
 classes
In-Reply-To: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528310.1387545321000.40164.1389610952789@jira02.app.mwc.hst.phx2.redhat.com>


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

Matus Abaffy closed WFLY-2722.
------------------------------


    
> @EJB injection in interceptor class and in target class result in injection of instances of two different classes
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2722
>                 URL: https://issues.jboss.org/browse/WFLY-2722
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Matus Abaffy
>            Assignee: Jozef Hartinger
>
> Interceptors spec, 2.2.1 - Interceptor Environment:
> bq. Interceptor class shares the enterprise naming context of its associated target class. (1)
> Assume the following scenario:
> Ear: test-ejb.jar, test1.war, test2.war
>   test-ejb.jar: Animal, BarBinding
>   test1.war: BarInterceptor, Dog
>   test2.war: Bar, Cat
> Short description of the classes:
> {code}
> @Stateful public class Dog implements Animal {...}
> {code}
> {code}
> @Stateful public class Cat implements Animal {...}
> {code}
> {code}
> @BarBinding @Stateless
> public class Bar {
>     @EJB
>     Animal animal;
> }
> {code}
> {code}
> @BarBinding @Priority(1000) @Interceptor
> public class BarInterceptor {
>     @EJB
>     Animal animal;
> }
> {code}
> Bar gets injected an instance of Cat, whereas BarInterceptor gets injected an instance of Dog, which IMHO contradicts (1).
> Test case at: https://github.com/cdi-spec/cdi-tck/pull/38
> (InterceptorEnvironmentJNDITest, InterceptorEnvironmentJNDISessionBeanTest)

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

From issues at jboss.org  Mon Jan 13 06:18:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 13 Jan 2014 06:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2737) Application that deploys in
 8.0.0.BETA does not deploy in 8.0.0.CR1
In-Reply-To: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529118.1389369416000.40194.1389611913200@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-2737:
--------------------------------------

This is an @Provider class, which we are treating as a bean defining annotation to allow CDI injection to work.  
                
> Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
> -------------------------------------------------------------------
>
>                 Key: WFLY-2737
>                 URL: https://issues.jboss.org/browse/WFLY-2737
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Zelivinski
>            Assignee: Jozef Hartinger
>
> We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
> 16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field:  [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
> 	at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
> 	at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
> 	at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
> 	at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> We are not able to identify the cause for this. Please help.

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

From issues at jboss.org  Mon Jan 13 06:18:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 13 Jan 2014 06:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2748) Review use of
	CurrentServiceContainer
In-Reply-To: <JIRA.12529190.1389611902858@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529190.1389611902858@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529190.1389611902858.40200.1389611913562@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2748:
------------------------------------

             Summary: Review use of CurrentServiceContainer
                 Key: WFLY-2748
                 URL: https://issues.jboss.org/browse/WFLY-2748
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


It looks like this is being used in some places where there is other options 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 issues at jboss.org  Mon Jan 13 06:56:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 06:56:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2743) Some static references are
 stored to the ServiceRegistry that do not have permission checks
In-Reply-To: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529147.1389428365000.40267.1389614192876@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2743:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1051751, https://bugzilla.redhat.com/show_bug.cgi?id=1052141  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1051751)

    
> Some static references are stored to the ServiceRegistry that do not have permission checks
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2743
>                 URL: https://issues.jboss.org/browse/WFLY-2743
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This enables a deployment to get access to the MSC ServiceRegistry, and from there change internal server state without any security manager checks. 

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

From issues at jboss.org  Mon Jan 13 07:52:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 13 Jan 2014 07:52:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2737) Application that deploys in
 8.0.0.BETA does not deploy in 8.0.0.CR1
In-Reply-To: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529118.1389369416000.40471.1389617553357@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-2737:
---------------------------------------

Yes, but this applies to classes in deployment, not to classes within bundles libraries. Anyway, I sent a PR for RESTEasy: https://github.com/resteasy/Resteasy/pull/438
                
> Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
> -------------------------------------------------------------------
>
>                 Key: WFLY-2737
>                 URL: https://issues.jboss.org/browse/WFLY-2737
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Zelivinski
>            Assignee: Jozef Hartinger
>
> We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
> 16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field:  [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
> 	at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
> 	at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
> 	at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
> 	at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> We are not able to identify the cause for this. Please help.

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

From issues at jboss.org  Mon Jan 13 08:10:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.40491.1389618632769@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2746:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1052187

    
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 08:10:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.40493.1389618632881@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935278#comment-12935278 ] 

RH Bugzilla Integration commented on WFLY-2746:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1052187|https://bugzilla.redhat.com/show_bug.cgi?id=1052187] from NEW to ASSIGNED
                
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 08:14:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Jan 2014 08:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.40497.1389618872774@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-2746.
------------------------------

    Resolution: Done

    
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 08:14:32 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Jan 2014 08:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.40500.1389618872963@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-2746.
----------------------------


    
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 08:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-89) LogContext's root logger is
 not created with a strong child hash map when strong=true
In-Reply-To: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525357.1384544962000.40534.1389619953473@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated LOGMGR-89:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1031221, https://bugzilla.redhat.com/show_bug.cgi?id=1052198  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1031221)

    
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-89
>                 URL: https://issues.jboss.org/browse/LOGMGR-89
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>             Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
>   <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <logger name="com.redhat" additivity="false">
>     <level value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP_MDB"/>
>   </logger>
>   <root>
>     <priority value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP"/>
>   </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used.  One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO  [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {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 issues at jboss.org  Mon Jan 13 08:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-89) LogContext's root logger is
 not created with a strong child hash map when strong=true
In-Reply-To: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525357.1384544962000.40543.1389619953833@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935284#comment-12935284 ] 

RH Bugzilla Integration commented on LOGMGR-89:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1052198|https://bugzilla.redhat.com/show_bug.cgi?id=1052198] from NEW to MODIFIED
                
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-89
>                 URL: https://issues.jboss.org/browse/LOGMGR-89
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>             Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
>   <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <logger name="com.redhat" additivity="false">
>     <level value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP_MDB"/>
>   </logger>
>   <root>
>     <priority value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP"/>
>   </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used.  One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO  [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {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 issues at jboss.org  Mon Jan 13 08:54:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:54:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.40589.1389621273043@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935292#comment-12935292 ] 

RH Bugzilla Integration commented on WFLY-2498:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1051171|https://bugzilla.redhat.com/show_bug.cgi?id=1051171] from ASSIGNED to MODIFIED
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Mon Jan 13 08:54:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:54:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.40592.1389621273162@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935293#comment-12935293 ] 

RH Bugzilla Integration commented on WFLY-2513:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1051205|https://bugzilla.redhat.com/show_bug.cgi?id=1051205] from POST to MODIFIED
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Mon Jan 13 08:56:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.40596.1389621393025@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935294#comment-12935294 ] 

RH Bugzilla Integration commented on WFLY-2660:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1051240|https://bugzilla.redhat.com/show_bug.cgi?id=1051240] from POST to MODIFIED
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 08:56:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 08:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.40607.1389621393481@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935297#comment-12935297 ] 

RH Bugzilla Integration commented on WFLY-1594:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1051189|https://bugzilla.redhat.com/show_bug.cgi?id=1051189] from POST to MODIFIED
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 09:06:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 09:06:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.40626.1389621992889@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935304#comment-12935304 ] 

RH Bugzilla Integration commented on WFLY-2746:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1052187|https://bugzilla.redhat.com/show_bug.cgi?id=1052187] from ASSIGNED to POST
                
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:11:32 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 13 Jan 2014 10:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2744) JPA .schema-generation-action
 compliance issue
In-Reply-To: <JIRA.12529153.1389471913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529153.1389471913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529153.1389471913000.40758.1389625892826@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935332#comment-12935332 ] 

Scott Marlow commented on WFLY-2744:
------------------------------------

Please create a Hibernate https://hibernate.onjira.com/browse/HHH jira for this.  
                
> JPA .schema-generation-action compliance issue
> ----------------------------------------------
>
>                 Key: WFLY-2744
>                 URL: https://issues.jboss.org/browse/WFLY-2744
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Leos Literak
>            Assignee: Scott Marlow
>
> I had following persistence.xml in my war application:
> <?xml version="1.0" encoding="UTF-8"?>
> <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://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
>   <persistence-unit name="OAUTHDEMO" transaction-type="JTA">
>     <jta-data-source>java:jboss/datasources/test</jta-data-source>
>     <exclude-unlisted-classes>false</exclude-unlisted-classes>
>     <properties>
>         <property name="javax.persistence.schema-generation.database.action" value="create"/>
>     </properties>
>   </persistence-unit>
> </persistence>
> When I ran it second time, deployment failed because table already existed. I downloaded JPA specification to read how it is defined and there is such statement:
> javax.persistence.schema-generation-action
> The javax.persistence.schema-generation-action property specifies the
> action to be taken by the persistence provider. If the javax.persistence.
> schema-generation-target property is not specified, no action must be
> taken, regardless of the value of the javax.persistence.schema-generation-
> action property. The values for this property are "none", "create",
> "drop-and-create", "drop".
> Following sentence is interesting, because I do not have the schema-generation-target property defined:
> If the javax.persistence.
> schema-generation-target property is not specified, no action must be
> taken, regardless of the value of the javax.persistence.schema-generation-action property. 
> So unless I misunderstood this line, then JPA implementation is incorrect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:13:33 2014
From: issues at jboss.org (Kevin Formsma (JIRA))
Date: Mon, 13 Jan 2014 10:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946070@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946070@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946070.40764.1389626013984@jira02.app.mwc.hst.phx2.redhat.com>

Kevin Formsma created WFLY-2749:
-----------------------------------

             Summary: Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
                 Key: WFLY-2749
                 URL: https://issues.jboss.org/browse/WFLY-2749
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBoss AS7 7.2.0.Final
            Reporter: Kevin Formsma


Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".

{code:xml}
        <xa-pool>
            <no-tx-separate-pools/>
        </xa-pool>
{code}

Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:17:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 13 Jan 2014 10:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.40777.1389626253297@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935335#comment-12935335 ] 

Tomaz Cerar commented on WFLY-2749:
-----------------------------------

What does the whole configuration look like?
                
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:17:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 13 Jan 2014 10:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.40781.1389626253484@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2749:
------------------------------

    Component/s: JCA

    
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:17:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 13 Jan 2014 10:17:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.40784.1389626253618@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2749:
------------------------------

    Assignee: Stefano Maestri

    
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>            Assignee: Stefano Maestri
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:27:32 2014
From: issues at jboss.org (Kevin Formsma (JIRA))
Date: Mon, 13 Jan 2014 10:27:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.40801.1389626852929@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935338#comment-12935338 ] 

Kevin Formsma commented on WFLY-2749:
-------------------------------------

Datasource:
{code:xml}
<xa-datasource jta="true" jndi-name="java:/leanEJB" pool-name="leanEJB" enabled="true" use-ccm="true">
        <xa-datasource-property name="URL">...</xa-datasource-property>
        <xa-datasource-property name="User">...</xa-datasource-property>
        <xa-datasource-property name="Password">...</xa-datasource-property> -->
        <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
        <driver>oracle</driver>
        <new-connection-sql>...</new-connection-sql>
        <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
        <xa-pool>
            <no-tx-separate-pools/>
            <min-pool-size>0</min-pool-size>
            <max-pool-size>20</max-pool-size>
            <prefill>true</prefill>
            <flush-strategy>IdleConnections</flush-strategy>
        </xa-pool>
        <validation>
            <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
            <background-validation>true</background-validation>
            <background-validation-millis>60000</background-validation-millis>
            <use-fast-fail>true</use-fast-fail>
            <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/>
            <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
        </validation>
        <timeout>
            <idle-timeout-minutes>15</idle-timeout-minutes>
        </timeout>
        <recovery no-recovery="true"/>
</xa-datasource>
{code}
Driver
{code:xml}
                    <driver name="oracle" module="com.oracle.ojdbc6">
                        <xa-datasource-class>oracle.jdbc.OracleDriver</xa-datasource-class>
                    </driver>
{code}
                
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>            Assignee: Stefano Maestri
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:31:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 13 Jan 2014 10:31:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2743) Some static references are
 stored to the ServiceRegistry that do not have permission checks
In-Reply-To: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529147.1389428365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529147.1389428365000.40807.1389627093174@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened WFLY-2743:
----------------------------------


    
> Some static references are stored to the ServiceRegistry that do not have permission checks
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2743
>                 URL: https://issues.jboss.org/browse/WFLY-2743
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> This enables a deployment to get access to the MSC ServiceRegistry, and from there change internal server state without any security manager checks. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 10:43:34 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Mon, 13 Jan 2014 10:43:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.40869.1389627814389@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935348#comment-12935348 ] 

Scott Hasse commented on AS7-1389:
----------------------------------

We seem to be in agreement that point 1) above provides the strongest argument for explicit visibility to third party logging APIs and implementations.  So I think it makes sense to tackle that one first, and if it can't be overcome, then we don't need to spend time with any of the rest.  In that spirit, it is probably worth clarifying exactly what sort of transition I was talking about when I made my request to "Please consider re-thinking this decision moving forward.".

If we're talking about modifications to the existing EAP 6 major version, then I agree it would not be prudent to introduce a compatibility-breaking change.

However, my impression of transitions between major versions is that customers should very much expect (with minor exceptions) compatibility-breaking changes.  Specifically the notes here:

https://access.redhat.com/site/support/policy/updates/jboss_notes/

state "Red Hat's goal is to maintain compatibility across the full life cycle of a product family (e.g., EAP 5.x patches, EAP 5.x CPs, and EAP 5.x releases are in the same EAP 5 product family).".  The subtext of that, and what we have been explicitly told by every TAM I've worked with, as well as multiple support personnel and senior RedHat developers, is that between major EAP versions (e.g. 5.x -> 6.x -> 7.x) we should certainly expect compatibility-breaking changes and that even paying customers will have to deal with them.  

Even only considering the sorts of changes that are primarily developer/deployer-facing (rather than, for instance changes to the configuration management facilities), we've seen major compatibility-breaking changes during both the EAP 4.x to 5.x transition (VFS broke Spring 2 and deployment order changed in incompatible ways for instance) and EAP 5.x to 6.x (JNDI, modules implementation and many others).

It seems to me that defaulting to not exposing third-party logging APIs and implementations (especially with an easy "switch" to flip to enable visibility for those requiring it) is minor compared to many of those previous compatibility-breaking changes.  Therefore it further seems that, strictly in the context of a major version transition such as to EAP 7.x, "compatibility requirements" taken on its own does not seem to be a valid reason to drop consideration of this change.

I'm interested to understand if I've gotten something wrong with respect to expectations around major EAP versions and compatibility.  If so there would be a number of support cases I could re-address.

Regards,

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Mon Jan 13 10:45:34 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 13 Jan 2014 10:45:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2744) JPA .schema-generation-action
 compliance issue
In-Reply-To: <JIRA.12529153.1389471913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529153.1389471913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529153.1389471913000.40879.1389627934425@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2744.
--------------------------------

    Resolution: Rejected


When you create the Hibernate jira for this issue, include the error message that causes deployment to fail.  
                
> JPA .schema-generation-action compliance issue
> ----------------------------------------------
>
>                 Key: WFLY-2744
>                 URL: https://issues.jboss.org/browse/WFLY-2744
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Leos Literak
>            Assignee: Scott Marlow
>
> I had following persistence.xml in my war application:
> <?xml version="1.0" encoding="UTF-8"?>
> <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://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
>   <persistence-unit name="OAUTHDEMO" transaction-type="JTA">
>     <jta-data-source>java:jboss/datasources/test</jta-data-source>
>     <exclude-unlisted-classes>false</exclude-unlisted-classes>
>     <properties>
>         <property name="javax.persistence.schema-generation.database.action" value="create"/>
>     </properties>
>   </persistence-unit>
> </persistence>
> When I ran it second time, deployment failed because table already existed. I downloaded JPA specification to read how it is defined and there is such statement:
> javax.persistence.schema-generation-action
> The javax.persistence.schema-generation-action property specifies the
> action to be taken by the persistence provider. If the javax.persistence.
> schema-generation-target property is not specified, no action must be
> taken, regardless of the value of the javax.persistence.schema-generation-
> action property. The values for this property are "none", "create",
> "drop-and-create", "drop".
> Following sentence is interesting, because I do not have the schema-generation-target property defined:
> If the javax.persistence.
> schema-generation-target property is not specified, no action must be
> taken, regardless of the value of the javax.persistence.schema-generation-action property. 
> So unless I misunderstood this line, then JPA implementation is incorrect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 11:01:35 2014
From: issues at jboss.org (Stan Zelivinski (JIRA))
Date: Mon, 13 Jan 2014 11:01:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2737) Application that deploys in
 8.0.0.BETA does not deploy in 8.0.0.CR1
In-Reply-To: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529118.1389369416000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529118.1389369416000.40907.1389628895556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935356#comment-12935356 ] 

Stan Zelivinski commented on WFLY-2737:
---------------------------------------

After I changed the pom and added   <scope>provided</scope> to all RESTEasy jars dependencies I could deploy my application. Still need to change, rebuild and retest all applications that we are building to run on CR1, so in our opinion it is an issue to be fixed.
                
> Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
> -------------------------------------------------------------------
>
>                 Key: WFLY-2737
>                 URL: https://issues.jboss.org/browse/WFLY-2737
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Zelivinski
>            Assignee: Jozef Hartinger
>
> We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
> 16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field:  [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
> 	at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
> 	at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
> 	at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
> 	at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> We are not able to identify the cause for this. Please help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 11:01:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 11:01:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.40911.1389628895796@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2319:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014911, https://bugzilla.redhat.com/show_bug.cgi?id=1050184  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1014911)

    
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>         Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 11:15:33 2014
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Mon, 13 Jan 2014 11:15:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2750) Missing break for
 CommonIronJacamarParser.java
In-Reply-To: <JIRA.12529241.1389629620863@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529241.1389629620863@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529241.1389629620863.40940.1389629733675@jira02.app.mwc.hst.phx2.redhat.com>

Rostislav Svoboda created WFLY-2750:
---------------------------------------

             Summary: Missing break for CommonIronJacamarParser.java
                 Key: WFLY-2750
                 URL: https://issues.jboss.org/browse/WFLY-2750
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA
            Reporter: Rostislav Svoboda
            Assignee: Rostislav Svoboda


https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/resourceadapters/CommonIronJacamarParser.java#L178

unterminated case for SHARABLE:
{code}
   case USE_CCM: {
                    USE_CCM.parseAndSetParameter(value, connectionDefinitionNode, reader);
                    break;
                }

                case SHARABLE: {
                    SHARABLE.parseAndSetParameter(value, connectionDefinitionNode, reader);
                }

                case ENLISTMENT: {
                    ENLISTMENT.parseAndSetParameter(value, connectionDefinitionNode, reader);
                    break;
                }
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 16:12:32 2014
From: issues at jboss.org (Michael Wang (JIRA))
Date: Mon, 13 Jan 2014 16:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-319) "Unknown boolean operator"
 RuntimeException
In-Reply-To: <JIRA.12517975.1383602931000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12517975.1383602931000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12517975.1383602931000.41555.1389647552859@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935436#comment-12935436 ] 

Michael Wang commented on DROOLS-319:
-------------------------------------

Hi, Dave, could you provide some details on how you debugged it? I got exactly the same error but I didn't have the condition pattern as you mentioned.
                
> "Unknown boolean operator" RuntimeException
> -------------------------------------------
>
>                 Key: DROOLS-319
>                 URL: https://issues.jboss.org/browse/DROOLS-319
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows 8, java version "1.7.0_40"
>            Reporter: David Tombs
>            Assignee: Mark Proctor
>
> Steps to reproduce:
> # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
> # Execute the rule against a few objects.
> Actual Result:
> An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
> {noformat}
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> 	at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> 	at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> 	at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> 	at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> 	at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> 	at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> 	at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> 	at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> 	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:724)
> {noformat}
> Expected Result:
> Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did 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 issues at jboss.org  Mon Jan 13 16:50:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 16:50:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot
 find custom ldap socket factory
In-Reply-To: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529141.1389397970000.41610.1389649832783@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-784:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1052644

    
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
>                 Key: SECURITY-784
>                 URL: https://issues.jboss.org/browse/SECURITY-784
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the  "java.naming.ldap.factory.socket" property in as an
> module-option:
>   <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
>      at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
>      at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
>      at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
>      at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk.  Unfortunately, that did not work.  I also added the socket
> factory jar to the jre/lib/ext directory.  That didn't work either.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 13 18:26:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 13 Jan 2014 18:26:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.41719.1389655592719@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935459#comment-12935459 ] 

RH Bugzilla Integration commented on WFLY-2746:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1052187|https://bugzilla.redhat.com/show_bug.cgi?id=1052187] from POST to MODIFIED
                
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 02:45:33 2014
From: issues at jboss.org (Paa Kojo Konduah Amos (JIRA))
Date: Tue, 14 Jan 2014 02:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.42028.1389685533750@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935497#comment-12935497 ] 

Paa Kojo Konduah Amos commented on WFLY-2729:
---------------------------------------------

Thanks Guys, I am really grateful that you've made things clearer to me...I must also add that, sometimes when such warnings are even ignored deployments sometimes fails. But that notwithstanding i get the whole picture now.

Thanks again.
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Tue Jan 14 02:47:33 2014
From: issues at jboss.org (Paa Kojo Konduah Amos (JIRA))
Date: Tue, 14 Jan 2014 02:47:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.42035.1389685653231@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935497#comment-12935497 ] 

Paa Kojo Konduah Amos edited comment on WFLY-2729 at 1/14/14 2:47 AM:
----------------------------------------------------------------------

Thanks Guys, I am really grateful that you've made things clearer to me...I must also add that, sometimes when such warnings are even ignored deployments fails. But that notwithstanding i get the whole picture now.

Thanks again.
                
      was (Author: pkkamos):
    Thanks Guys, I am really grateful that you've made things clearer to me...I must also add that, sometimes when such warnings are even ignored deployments sometimes fails. But that notwithstanding i get the whole picture now.

Thanks again.
                  
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Tue Jan 14 05:15:34 2014
From: issues at jboss.org (Matus Abaffy (JIRA))
Date: Tue, 14 Jan 2014 05:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2722) @EJB injection in interceptor
 class and in target class result in injection of instances of two different
 classes
In-Reply-To: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528310.1387545321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528310.1387545321000.42377.1389694534071@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935551#comment-12935551 ] 

Matus Abaffy commented on WFLY-2722:
------------------------------------

Thanks for your explanation.
Using InitialContext.doLookup("java:module/Animal"); in BarInterceptor returns the expected instance of Cat (assuming @Stateful(name = "Animal") annotation on Dog and Cat) so there is no need to use @EJB there.
                
> @EJB injection in interceptor class and in target class result in injection of instances of two different classes
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2722
>                 URL: https://issues.jboss.org/browse/WFLY-2722
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Matus Abaffy
>            Assignee: Jozef Hartinger
>
> Interceptors spec, 2.2.1 - Interceptor Environment:
> bq. Interceptor class shares the enterprise naming context of its associated target class. (1)
> Assume the following scenario:
> Ear: test-ejb.jar, test1.war, test2.war
>   test-ejb.jar: Animal, BarBinding
>   test1.war: BarInterceptor, Dog
>   test2.war: Bar, Cat
> Short description of the classes:
> {code}
> @Stateful public class Dog implements Animal {...}
> {code}
> {code}
> @Stateful public class Cat implements Animal {...}
> {code}
> {code}
> @BarBinding @Stateless
> public class Bar {
>     @EJB
>     Animal animal;
> }
> {code}
> {code}
> @BarBinding @Priority(1000) @Interceptor
> public class BarInterceptor {
>     @EJB
>     Animal animal;
> }
> {code}
> Bar gets injected an instance of Cat, whereas BarInterceptor gets injected an instance of Dog, which IMHO contradicts (1).
> Test case at: https://github.com/cdi-spec/cdi-tck/pull/38
> (InterceptorEnvironmentJNDITest, InterceptorEnvironmentJNDISessionBeanTest)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 10:49:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Tue, 14 Jan 2014 10:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544263@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544263@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544263.43427.1389714573476@jira02.app.mwc.hst.phx2.redhat.com>

Andre Pankraz created WFLY-2751:
-----------------------------------

             Summary: h:inputFile and max-file-size
                 Key: WFLY-2751
                 URL: https://issues.jboss.org/browse/WFLY-2751
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
         Environment: Open JDK 7, Cent OS
            Reporter: Andre Pankraz
            Assignee: Stuart Douglas


If I use h:inputFile (JSF) together with something like e.g.:

	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
		<multipart-config>
			<location>/tmp</location>
			<max-file-size>1000</max-file-size>
			<max-request-size>2000</max-request-size>
			<file-size-threshold>500</file-size-threshold>
		</multipart-config>
	</servlet>

and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).

I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!

Exception is:
16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	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.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	... 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 issues at jboss.org  Tue Jan 14 10:51:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Tue, 14 Jan 2014 10:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.43430.1389714693307@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andre Pankraz updated WFLY-2751:
--------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	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.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 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 issues at jboss.org  Tue Jan 14 10:51:33 2014
From: issues at jboss.org (Stefan Jansen (JIRA))
Date: Tue, 14 Jan 2014 10:51:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.43437.1389714693728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935660#comment-12935660 ] 

Stefan Jansen commented on DROOLS-373:
--------------------------------------

I got the same problem and bypass it adding the project dependency as a dependency to the kie-maven-plugin:

{code:xml}
            <plugin>
                <groupId>org.kie</groupId>
                <artifactId>kie-maven-plugin</artifactId>
                <version>6.0.1.Final</version>
                <extensions>true</extensions>
                <dependencies>        
			<dependency>
				<groupId>org.apache.commons</groupId>
				<artifactId>commons-lang3</artifactId>
				<version>3.1</version>
			</dependency>
                </dependencies>
            </plugin>
{code}

Don't think this is the supposed solution. If it is, I think it should be documented.
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools6scratch-kiemavenclasspath.zip
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Tue Jan 14 12:15:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 14 Jan 2014 12:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2623) Unable to change process-id
 mechanism from process-id-uuid to process-id-socket-binding on transaction
In-Reply-To: <JIRA.12527292.1386568161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527292.1386568161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527292.1386568161000.43612.1389719733990@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935693#comment-12935693 ] 

RH Bugzilla Integration commented on WFLY-2623:
-----------------------------------------------

Amos Feng <zfeng at redhat.com> changed the Status of [bug 1036739|https://bugzilla.redhat.com/show_bug.cgi?id=1036739] from NEW to POST
                
> Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction 
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2623
>                 URL: https://issues.jboss.org/browse/WFLY-2623
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Amos Feng
>            Assignee: Hayk Hovsepyan
>              Labels: transaction
>             Fix For: 8.0.0.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1036739
> process-id mechanism can not be changed from process-id-uuid to process-id-socket-binding.
> The following ERROR occurred at JBoss start-up:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 44) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "JBAS014746: process-id-uuid may not be null"
> {noformat}
> The root reason is it does not check the PROCESS_ID_UUID if defined when booting the coreEnvironment service in TransactionSubsytemAdd.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 12:51:32 2014
From: issues at jboss.org (Stan Zelivinski (JIRA))
Date: Tue, 14 Jan 2014 12:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2752) Using an injected UriInfo
 object by the JAX-RS runtime environment does not work
In-Reply-To: <JIRA.12529422.1389721819386@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529422.1389721819386@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529422.1389721819386.43645.1389721892832@jira02.app.mwc.hst.phx2.redhat.com>

Stan Zelivinski created WFLY-2752:
-------------------------------------

             Summary: Using an injected UriInfo object by the JAX-RS runtime environment does not work
                 Key: WFLY-2752
                 URL: https://issues.jboss.org/browse/WFLY-2752
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: REST
    Affects Versions: 8.0.0.CR1
         Environment: Linux Fedora
            Reporter: Stan Zelivinski
            Assignee: Stuart Douglas


The code that works perfectly in WildFly.8.0.0.Beta:

package jdsu.vts.tcpcontroller.webservices.rest.resources;

import java.net.URI;

import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.Consumes;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.UriInfo;

import jdsu.vts.tcpcontroller.webservices.rest.application.V1_TCPController;
import jdsu.vts.shared.transferobjects.V1_TCPSetups;

@Path("/v1")
public class V1_TCPControllerResource {

	@Context UriInfo uriInfo;
	
	@GET
	@Produces("application/json")
	/**
	 * 
	 * @return
	 */
	public Response getControllers() {
		
		//String json = String.valueOf(m_testsMap.size());	
		return Response.ok(V1_TCPController.getCollection()).build();
	}
	
	@PUT
	@Path("{id}")	
	@Produces("application/json")
	public Response addController(@PathParam("id") String id){
		
		V1_TCPController controller = V1_TCPController.find(id);
		if(controller != null) {			
			return Response.status(Response.Status.CONFLICT).build();
		}
		
		controller = new V1_TCPController(id);
		
		URI uri = uriInfo.getAbsolutePathBuilder().path(id).build();
		
		return Response.created(uri).build();

	}
}

does not work in WildFly.8.0.0.CR1. uriInfo is null in the call.

Please help.
Stan


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 16:05:33 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Tue, 14 Jan 2014 16:05:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001000.43808.1389733533115@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935734#comment-12935734 ] 

leonardo lizana commented on DROOLS-394:
----------------------------------------

Thank you for you replay. Yes, it an issue of a object null. This issue has been already solved on my side. it can be closed.

Thank you again.
                
> java.lang.RuntimeException: cannot invoke getter
> ------------------------------------------------
>
>                 Key: DROOLS-394
>                 URL: https://issues.jboss.org/browse/DROOLS-394
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>
> we are using drools 5.4.final. and below is the rule
> rule "EnergyUsage data not empty"
>       dialect "java"	
>       salience 100
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup!=null && ((EnergyUsage)responseData).energyUsageDetail.billingGroup!=0) || 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()>0 ||
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()>0 ||
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint!=null ||
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() > 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data not empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("");
> end
> rule "EnergyUsage data empty"
>       dialect "java"	
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup==null || ((EnergyUsage)responseData).energyUsageDetail.billingGroup==0) && 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()==0 &&
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()==0 &&
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint==null &&
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() == 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("Data Screen Scrapping is empty for this account");
> end
> Here is log error:
> -------------------------
> java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
>         at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
>         at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>         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:337)
>         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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
>         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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy161.ruleCompliance(Unknown Source)
>         at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 16:07:33 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Tue, 14 Jan 2014 16:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238000.43814.1389733653558@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935736#comment-12935736 ] 

leonardo lizana commented on DROOLS-396:
----------------------------------------

any update?
                
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-396
>                 URL: https://issues.jboss.org/browse/DROOLS-396
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>            Priority: Critical
>
> I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
> is there anything that i'm doing bad?
> * with drools 5.5 everything is working OK.
> Here is my pom.xml
> --------------------------
> <dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>knowledge-api</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-core</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-compiler</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-spring</artifactId>
> 			<version>5.5.0.Final</version>
> 		</dependency>
> here is the log error:
> ----------------------------
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> 	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
> 	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
> 	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
> 	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
> 	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
> 	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
> 	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
> 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
> 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
> Here is the contex-drools.xml
> -------------------------------------
> <beans xmlns="http://www.springframework.org/schema/beans"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:context="http://www.springframework.org/schema/context"
>     xmlns:drools="http://drools.org/schema/drools-spring"
>     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
>     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
>     http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
>     default-autowire="byName">
>      
>   <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
>   <drools:kbase id="kBaseEnergyUsage">
>     <drools:resources>
>       <drools:resource ref="rulesEnergyUsage"/>
>     </drools:resources>
>   </drools:kbase>
>   <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
>  </beans>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 16:07:33 2014
From: issues at jboss.org (leonardo lizana (JIRA))
Date: Tue, 14 Jan 2014 16:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-394) java.lang.RuntimeException:
 cannot invoke getter
In-Reply-To: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528914.1389223001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528914.1389223001000.43812.1389733653407@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

leonardo lizana closed DROOLS-394.
----------------------------------

    Fix Version/s: 5.5.1.Final
       Resolution: Done


issue is due to an object null
                
> java.lang.RuntimeException: cannot invoke getter
> ------------------------------------------------
>
>                 Key: DROOLS-394
>                 URL: https://issues.jboss.org/browse/DROOLS-394
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>             Fix For: 5.5.1.Final
>
>
> we are using drools 5.4.final. and below is the rule
> rule "EnergyUsage data not empty"
>       dialect "java"	
>       salience 100
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup!=null && ((EnergyUsage)responseData).energyUsageDetail.billingGroup!=0) || 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()>0 ||
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()>0 ||
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint!=null ||
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() > 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data not empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("");
> end
> rule "EnergyUsage data empty"
>       dialect "java"	
>       no-loop
>   when
>       $httpResponse : HttpResponse(
> 									(((EnergyUsage)responseData).energyUsageDetail.billingGroup==null || ((EnergyUsage)responseData).energyUsageDetail.billingGroup==0) && 
>       								((EnergyUsage)responseData).energyUsageDetail.capacityPLCs.size()==0 &&
> 									((EnergyUsage)responseData).energyUsageDetail.networkServicePLCs.size()==0 &&
>       								((EnergyUsage)responseData).energyUsageDetail.servicePoint==null &&
>       								((EnergyUsage)responseData).energyUsageDetail.historicalUsages.size() == 0
>       					);
>       					
>      
>   then
>       System.out.println("[EnergyUsage data empty] rule has been fired...");
>       $httpResponse.setStatusCode(EisConstants.STATUS_OK);
>       $httpResponse.setErrorMessage("Data Screen Scrapping is empty for this account");
> end
> Here is log error:
> -------------------------
> java.lang.RuntimeException: cannot invoke getter: getEnergyUsageDetail [declr.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage; act.class: com.bluestarenergy.core.eis.common.usage.EnergyUsage] (see trace)
>         at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:74)
>         at org.mvel2.ast.Union.getReducedValueAccelerated(Union.java:41)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:107)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.ast.Or.getReducedValueAccelerated(Or.java:34)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:123)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:49)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:124)
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>         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:337)
>         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.aepenergy.b2b.services.energyusage.UsageRulesServiceImpl.ruleCompliance(UsageRulesServiceImpl.java:19)
>         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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>         at $Proxy161.ruleCompliance(Unknown Source)
>         at com.aepenergy.b2b.services.energyusage.EnergyUsageCommunicationServiceImpl.processRequestEnergyUsageHttp(EnergyUsageCommunicationServiceImpl.java:52)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 14 16:45:33 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 14 Jan 2014 16:45:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-397) Don't hard code versions in
 drools-osgi's drools-karaf-features's pom
In-Reply-To: <JIRA.12529434.1389735844966@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529434.1389735844966@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529434.1389735844966.43863.1389735933630@jira02.app.mwc.hst.phx2.redhat.com>

Geoffrey De Smet created DROOLS-397:
---------------------------------------

             Summary: Don't hard code versions in drools-osgi's drools-karaf-features's pom
                 Key: DROOLS-397
                 URL: https://issues.jboss.org/browse/DROOLS-397
             Project: Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco


Historically, there we no versions available as properties from the ip-bom, so we hard coded them for karaff:
https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/pom.xml#L23

So we did:

{code}
<karaf.version.org.apache.camel>2.10.3</karaf.version.org.apache.camel>
{code}

But we extend the jboss-integration-platform-parent, so they are available:
   https://github.com/jboss-integration/jboss-integration-platform-bom/blob/master/pom.xml#L90

So now do:
{code}
<karaf.version.org.apache.camel>${version.org.apache.camel}</karaf.version.org.apache.camel>
{code}

etc.

Note: there are still a few special ones (the wrapper ones in that karaf features pom) that you might want to keep hard coded to get osgi to 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 issues at jboss.org  Wed Jan 15 00:13:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Wed, 15 Jan 2014 00:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705054@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705054@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705054.44099.1389762813145@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Lape created WFLY-2753:
-------------------------------

             Summary: Workaround for auditlog syslog appName not being configurable
                 Key: WFLY-2753
                 URL: https://issues.jboss.org/browse/WFLY-2753
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Kyle Lape
            Assignee: Kabir Khan
             Fix For: 8.0.0.Final


Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 00:13:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Wed, 15 Jan 2014 00:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.44101.1389762813246@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-2753:
----------------------------

    Description: Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424  (was: Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424)

    
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 00:15:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Wed, 15 Jan 2014 00:15:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2754) Make auditlog syslog appName
	configurable
In-Reply-To: <JIRA.12529445.1389762826444@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529445.1389762826444@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529445.1389762826444.44105.1389762933772@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Lape created WFLY-2754:
-------------------------------

             Summary: Make auditlog syslog appName configurable
                 Key: WFLY-2754
                 URL: https://issues.jboss.org/browse/WFLY-2754
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Kyle Lape
            Assignee: Kabir Khan
             Fix For: 8.0.0.Final


Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch. Once done the workaround in WFLY-2746 should 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 issues at jboss.org  Wed Jan 15 00:15:33 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Wed, 15 Jan 2014 00:15:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2754) Make auditlog syslog appName
	configurable
In-Reply-To: <JIRA.12529445.1389762826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529445.1389762826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529445.1389762826000.44108.1389762933941@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-2754:
----------------------------

    Description: Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch. Once done the workaround in WFLY-2753 should be removed  (was: Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch. Once done the workaround in WFLY-2746 should be removed)

    
> Make auditlog syslog appName configurable
> -----------------------------------------
>
>                 Key: WFLY-2754
>                 URL: https://issues.jboss.org/browse/WFLY-2754
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Some initial code in my https://github.com/kabir/wildfly/tree/audit-log-facility-mgmt-api branch. Once done the workaround in WFLY-2753 should 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 issues at jboss.org  Wed Jan 15 00:47:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 00:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.44112.1389764852925@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2753:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1053355  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1052187)

    
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 01:59:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 01:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.44160.1389769172808@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2753:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1053355, https://bugzilla.redhat.com/show_bug.cgi?id=1053382  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1053355)

    
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 02:15:34 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Wed, 15 Jan 2014 02:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-398) Drools & jbpms cannot be
 deployed on JBoss Fuse 6.0 / Karaf 2.3
In-Reply-To: <JIRA.12529450.1389770106266@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529450.1389770106266@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529450.1389770106266.44163.1389770134162@jira02.app.mwc.hst.phx2.redhat.com>

Charles Moulliard created DROOLS-398:
----------------------------------------

             Summary: Drools & jbpms cannot be deployed on JBoss Fuse 6.0 / Karaf 2.3
                 Key: DROOLS-398
                 URL: https://issues.jboss.org/browse/DROOLS-398
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Charles Moulliard
            Assignee: Mark Proctor


Due to refactoring of project kie-commons (merged with uberfire) and not longer required by jBPMN (to be verified), Drools and jbpmn 6.0.1.Final cannot be deployed anymore on JBoss Fuse / Karaf using the following features deployment command :

{code}
features:addurl mvn:org.drools/drools-karaf-features/6.0.1.Final/xml/features
karaf at root> features:install kie-spring
Error executing command: URL [mvn:org.kie.commons/kie-commons-cdi/6.0.1.Final] could not be resolved.
{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 issues at jboss.org  Wed Jan 15 02:19:33 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Wed, 15 Jan 2014 02:19:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-399) itest of Karaf are disabled
In-Reply-To: <JIRA.12529451.1389770282081@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529451.1389770282081@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529451.1389770282081.44166.1389770373143@jira02.app.mwc.hst.phx2.redhat.com>

Charles Moulliard created DROOLS-399:
----------------------------------------

             Summary: itest of Karaf are disabled 
                 Key: DROOLS-399
                 URL: https://issues.jboss.org/browse/DROOLS-399
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Charles Moulliard
            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 issues at jboss.org  Wed Jan 15 02:21:33 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Wed, 15 Jan 2014 02:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-399) itest of Karaf are disabled
In-Reply-To: <JIRA.12529451.1389770282000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529451.1389770282000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529451.1389770282000.44168.1389770493177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935779#comment-12935779 ] 

Charles Moulliard commented on DROOLS-399:
------------------------------------------

iTest of Karaf are disabled in the module (droolsjbpm-integration), this is why we haven't been able to detect that drools/jbpmn cannot run anymore on Karaf/JBoss Fuse since version 6.0.1-6.0.1.Final

https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/pom.xml

Related to issue : Drools-398
                
> itest of Karaf are disabled 
> ----------------------------
>
>                 Key: DROOLS-399
>                 URL: https://issues.jboss.org/browse/DROOLS-399
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            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 issues at jboss.org  Wed Jan 15 02:21:33 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Wed, 15 Jan 2014 02:21:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-400) jbpmn-audit-task should be
 OSGIFied (add OSGI MetaData)
In-Reply-To: <JIRA.12529452.1389770456661@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529452.1389770456661@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529452.1389770456661.44172.1389770493397@jira02.app.mwc.hst.phx2.redhat.com>

Charles Moulliard created DROOLS-400:
----------------------------------------

             Summary: jbpmn-audit-task should be OSGIFied (add OSGI MetaData)
                 Key: DROOLS-400
                 URL: https://issues.jboss.org/browse/DROOLS-400
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Charles Moulliard
            Assignee: Mark Proctor


Jar is not a bundle, no Bundle-SymbolicName mvn:org.jbpm/jbpm-human-task-audit/6.0.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 issues at jboss.org  Wed Jan 15 02:23:32 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Wed, 15 Jan 2014 02:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-401) OSGI Singleton option should
	not be used
In-Reply-To: <JIRA.12529454.1389770559833@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529454.1389770559833@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529454.1389770559833.44176.1389770612826@jira02.app.mwc.hst.phx2.redhat.com>

Charles Moulliard created DROOLS-401:
----------------------------------------

             Summary: OSGI Singleton option should not be used
                 Key: DROOLS-401
                 URL: https://issues.jboss.org/browse/DROOLS-401
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Charles Moulliard
            Assignee: Mark Proctor


OSGI Singleton Option should be used as we get this error when we update or restart  a bundle on Karaf/JBoss Fuse

{code}
Error executing command: Could not start bundle mvn:org.jbpm/jbpm-flow-builder/6.0.1.Final in feature(s) jbpm-6.0.1.Final: Unresolved constraint in bundle org.jbpm.flow.builder [388]: Singleton conflict.
{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 issues at jboss.org  Wed Jan 15 03:41:32 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 15 Jan 2014 03:41:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-355) Do not import
 com.sun.tools.xjc in drools-core and drools-compiler to fix drools on
 Karaff and Fuse
In-Reply-To: <JIRA.12526302.1385564131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526302.1385564131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526302.1385564131000.44245.1389775292715@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-355:
------------------------------------

    Summary: Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff and Fuse  (was: Do not import com.sun.tools.xjc in drools-core and drools-compiler)

    
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff and Fuse
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-355
>                 URL: https://issues.jboss.org/browse/DROOLS-355
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
>     String 'com.sun.tools.xjc'
> Found usages  (38 usages found)
>     drools-compiler  (7 usages found)
>         /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler  (1 usage found)
>             pom.xml  (1 usage found)
>                 (246: 15) com.sun.tools.xjc.*;resolution:=optional,
>         org.drools.compiler.builder.impl  (1 usage found)
>             KnowledgeBuilderFactoryServiceImpl.java  (1 usage found)
>                 (18: 8) import com.sun.tools.xjc.Options;
>         org.drools.compiler.runtime.pipeline.impl  (5 usages found)
>             DroolsJaxbHelperProviderImpl.java  (5 usages found)
>                 (77: 8) import com.sun.tools.xjc.BadCommandLineException;
>                 (78: 8) import com.sun.tools.xjc.ErrorReceiver;
>                 (79: 8) import com.sun.tools.xjc.ModelLoader;
>                 (80: 8) import com.sun.tools.xjc.Options;
>                 (81: 8) import com.sun.tools.xjc.model.Model;
>     drools-core  (2 usages found)
>         org.drools.core.builder.conf.impl  (2 usages found)
>             JaxbConfigurationImpl.java  (2 usages found)
>                 (28: 8) import com.sun.tools.xjc.Language;
>                 (34: 8) import com.sun.tools.xjc.Options;
>     kie-internal  (6 usages found)
>         /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal  (1 usage found)
>             pom.xml  (1 usage found)
>                 (27: 15) com.sun.tools.xjc;resolution:=optional,
>         org.kie.internal.builder  (3 usages found)
>             JaxbConfiguration.java  (1 usage found)
>                 (23: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactory.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactoryService.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>         org.kie.internal.builder.help  (2 usages found)
>             DroolsJaxbHelperProvider.java  (1 usage found)
>                 (29: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderHelper.java  (1 usage found)
>                 (30: 8) import com.sun.tools.xjc.Options;
>     knowledge-api  (8 usages found)
>         org.drools.builder  (3 usages found)
>             JaxbConfiguration.java  (1 usage found)
>                 (21: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactory.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactoryService.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>         org.drools.builder.help  (3 usages found)
>             DroolsJaxbHelperProvider.java  (1 usage found)
>                 (29: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderHelper.java  (2 usages found)
>                 (32: 8) import com.sun.tools.xjc.Language;
>                 (33: 8) import com.sun.tools.xjc.Options;
>         org.drools.impl  (1 usage found)
>             KnowledgeBuilderFactoryServiceImpl.java  (1 usage found)
>                 (16: 8) import com.sun.tools.xjc.Options;
>         org.drools.impl.adapters  (1 usage found)
>             JaxbConfigurationAdapter.java  (1 usage found)
>                 (3: 8) import com.sun.tools.xjc.Options;
> {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 issues at jboss.org  Wed Jan 15 03:43:33 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 15 Jan 2014 03:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-355) Do not import
 com.sun.tools.xjc in drools-core and drools-compiler to fix drools on
 Karaff and Fuse
In-Reply-To: <JIRA.12526302.1385564131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526302.1385564131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526302.1385564131000.44247.1389775413129@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935791#comment-12935791 ] 

Geoffrey De Smet commented on DROOLS-355:
-----------------------------------------

There is another reason why drools doesn't work on karaff, see the bottom of this issue: https://issues.apache.org/jira/browse/CAMEL-7017
                
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff and Fuse
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-355
>                 URL: https://issues.jboss.org/browse/DROOLS-355
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
>     String 'com.sun.tools.xjc'
> Found usages  (38 usages found)
>     drools-compiler  (7 usages found)
>         /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler  (1 usage found)
>             pom.xml  (1 usage found)
>                 (246: 15) com.sun.tools.xjc.*;resolution:=optional,
>         org.drools.compiler.builder.impl  (1 usage found)
>             KnowledgeBuilderFactoryServiceImpl.java  (1 usage found)
>                 (18: 8) import com.sun.tools.xjc.Options;
>         org.drools.compiler.runtime.pipeline.impl  (5 usages found)
>             DroolsJaxbHelperProviderImpl.java  (5 usages found)
>                 (77: 8) import com.sun.tools.xjc.BadCommandLineException;
>                 (78: 8) import com.sun.tools.xjc.ErrorReceiver;
>                 (79: 8) import com.sun.tools.xjc.ModelLoader;
>                 (80: 8) import com.sun.tools.xjc.Options;
>                 (81: 8) import com.sun.tools.xjc.model.Model;
>     drools-core  (2 usages found)
>         org.drools.core.builder.conf.impl  (2 usages found)
>             JaxbConfigurationImpl.java  (2 usages found)
>                 (28: 8) import com.sun.tools.xjc.Language;
>                 (34: 8) import com.sun.tools.xjc.Options;
>     kie-internal  (6 usages found)
>         /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal  (1 usage found)
>             pom.xml  (1 usage found)
>                 (27: 15) com.sun.tools.xjc;resolution:=optional,
>         org.kie.internal.builder  (3 usages found)
>             JaxbConfiguration.java  (1 usage found)
>                 (23: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactory.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactoryService.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>         org.kie.internal.builder.help  (2 usages found)
>             DroolsJaxbHelperProvider.java  (1 usage found)
>                 (29: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderHelper.java  (1 usage found)
>                 (30: 8) import com.sun.tools.xjc.Options;
>     knowledge-api  (8 usages found)
>         org.drools.builder  (3 usages found)
>             JaxbConfiguration.java  (1 usage found)
>                 (21: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactory.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderFactoryService.java  (1 usage found)
>                 (24: 8) import com.sun.tools.xjc.Options;
>         org.drools.builder.help  (3 usages found)
>             DroolsJaxbHelperProvider.java  (1 usage found)
>                 (29: 8) import com.sun.tools.xjc.Options;
>             KnowledgeBuilderHelper.java  (2 usages found)
>                 (32: 8) import com.sun.tools.xjc.Language;
>                 (33: 8) import com.sun.tools.xjc.Options;
>         org.drools.impl  (1 usage found)
>             KnowledgeBuilderFactoryServiceImpl.java  (1 usage found)
>                 (16: 8) import com.sun.tools.xjc.Options;
>         org.drools.impl.adapters  (1 usage found)
>             JaxbConfigurationAdapter.java  (1 usage found)
>                 (3: 8) import com.sun.tools.xjc.Options;
> {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 issues at jboss.org  Wed Jan 15 03:51:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 03:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-376) NullPointerException on
 JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is
 modified
In-Reply-To: <JIRA.12527774.1386839957000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527774.1386839957000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527774.1386839957000.44255.1389775892929@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935793#comment-12935793 ] 

RH Bugzilla Integration commented on DROOLS-376:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1040889|https://bugzilla.redhat.com/show_bug.cgi?id=1040889] from ON_QA to VERIFIED
                
> NullPointerException on JPAKnowledgeService.loadStatefulKnowledgeSession() when Collection is modified
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-376
>                 URL: https://issues.jboss.org/browse/DROOLS-376
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>
> - Using JPAKnowledgeService
> - Add two or more elements to Collection property which is referred by 'from' in a rule.
> {noformat}
> package org.drools.test
> import org.drools.compiler.Person
> import org.drools.compiler.Address
> rule rule1
> when
>  $p: Person($list : addresses)
>  $a: Address(street == "y") from $list
> then
>  $list.add( new Address("z") );
>  $list.add( new Address("w") );
> end
> {noformat}
> - Call JPAKnowledgeService.loadStatefulKnowledgeSession()
> Then NullPointerException is thrown
> {noformat}
> 2013-12-12 18:03:31,329 [main] |org.drools.persistence.SingleSessionCommandService| WARN  Could not commit session
> java.lang.RuntimeException: Unable to load session snapshot
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88) ~[classes/:na]
> 	at org.drools.persistence.SingleSessionCommandService.initExistingKnowledgeSession(SingleSessionCommandService.java:264) ~[classes/:na]
> 	at org.drools.persistence.SingleSessionCommandService.<init>(SingleSessionCommandService.java:196) ~[classes/:na]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.7.0_13]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [na:1.7.0_13]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.7.0_13]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [na:1.7.0_13]
> 	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.buildCommandService(KnowledgeStoreServiceImpl.java:101) [classes/:na]
> 	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadKieSession(KnowledgeStoreServiceImpl.java:84) [classes/:na]
> 	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadKieSession(KnowledgeStoreServiceImpl.java:1) [classes/:na]
> 	at org.kie.internal.persistence.jpa.JPAKnowledgeService.loadStatefulKnowledgeSession(JPAKnowledgeService.java:130) [kie-internal-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> 	at org.drools.persistence.session.JpaPersistentStatefulSessionTest.testFromNodeWithModifiedCollection(JpaPersistentStatefulSessionTest.java:562) [test-classes/:na]
> ...
> Caused by: java.lang.NullPointerException: null
> 	at org.drools.core.reteoo.FromNode.createRightTuple(FromNode.java:152) ~[classes/:na]
> 	at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:96) ~[classes/:na]
> 	at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:49) ~[classes/:na]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:348) ~[classes/:na]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[classes/:na]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[classes/:na]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller$PBActivationsFilter.fireRNEAs(ProtobufInputMarshaller.java:813) ~[classes/:na]
> 	at org.drools.core.reteoo.LeftInputAdapterNode.doInsertObject(LeftInputAdapterNode.java:258) ~[classes/:na]
> 	at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:199) ~[classes/:na]
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[classes/:na]
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288) ~[classes/:na]
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:499) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:476) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:250) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:157) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:116) ~[classes/:na]
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:1) ~[classes/:na]
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:83) ~[classes/:na]
> {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 issues at jboss.org  Wed Jan 15 03:53:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 03:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.44259.1389776012955@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2198:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014414, https://bugzilla.redhat.com/show_bug.cgi?id=1053426  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1014414)

    
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 03:57:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 15 Jan 2014 03:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2752) Using an injected UriInfo
 object by the JAX-RS runtime environment does not work
In-Reply-To: <JIRA.12529422.1389721819000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529422.1389721819000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529422.1389721819000.44266.1389776253094@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2752:
------------------------------------

    Assignee: Bill Burke  (was: Stuart Douglas)

    
> Using an injected UriInfo object by the JAX-RS runtime environment does not work
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2752
>                 URL: https://issues.jboss.org/browse/WFLY-2752
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST
>    Affects Versions: 8.0.0.CR1
>         Environment: Linux Fedora
>            Reporter: Stan Zelivinski
>            Assignee: Bill Burke
>
> The code that works perfectly in WildFly.8.0.0.Beta:
> package jdsu.vts.tcpcontroller.webservices.rest.resources;
> import java.net.URI;
> import javax.ws.rs.DELETE;
> import javax.ws.rs.GET;
> import javax.ws.rs.PUT;
> import javax.ws.rs.Path;
> import javax.ws.rs.PathParam;
> import javax.ws.rs.Produces;
> import javax.ws.rs.Consumes;
> import javax.ws.rs.core.Context;
> import javax.ws.rs.core.Response;
> import javax.ws.rs.core.UriInfo;
> import jdsu.vts.tcpcontroller.webservices.rest.application.V1_TCPController;
> import jdsu.vts.shared.transferobjects.V1_TCPSetups;
> @Path("/v1")
> public class V1_TCPControllerResource {
> 	@Context UriInfo uriInfo;
> 	
> 	@GET
> 	@Produces("application/json")
> 	/**
> 	 * 
> 	 * @return
> 	 */
> 	public Response getControllers() {
> 		
> 		//String json = String.valueOf(m_testsMap.size());	
> 		return Response.ok(V1_TCPController.getCollection()).build();
> 	}
> 	
> 	@PUT
> 	@Path("{id}")	
> 	@Produces("application/json")
> 	public Response addController(@PathParam("id") String id){
> 		
> 		V1_TCPController controller = V1_TCPController.find(id);
> 		if(controller != null) {			
> 			return Response.status(Response.Status.CONFLICT).build();
> 		}
> 		
> 		controller = new V1_TCPController(id);
> 		
> 		URI uri = uriInfo.getAbsolutePathBuilder().path(id).build();
> 		
> 		return Response.created(uri).build();
> 	}
> }
> does not work in WildFly.8.0.0.CR1. uriInfo is null in the call.
> Please help.
> Stan

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 03:59:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 03:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.44272.1389776372857@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935795#comment-12935795 ] 

RH Bugzilla Integration commented on WFLY-2198:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from NEW to POST
                
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 04:29:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 15 Jan 2014 04:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2755) Split Wildfly code base into
 separate repositories
In-Reply-To: <JIRA.12529462.1389778076689@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529462.1389778076689@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529462.1389778076689.44340.1389778172911@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2755:
------------------------------------

             Summary: Split Wildfly code base into separate repositories
                 Key: WFLY-2755
                 URL: https://issues.jboss.org/browse/WFLY-2755
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Build System
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 9.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 issues at jboss.org  Wed Jan 15 04:29:33 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 15 Jan 2014 04:29:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2755) Split Wildfly code base into
 separate repositories
In-Reply-To: <JIRA.12529462.1389778076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529462.1389778076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529462.1389778076000.44347.1389778173415@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2755:
------------------------------

    Description: 
For starters we need to split wildfly core out of WildFly repository.
This needs to include moving tests that are related only to core, such as domain testsuite, patching....

    
> Split Wildfly code base into separate repositories
> --------------------------------------------------
>
>                 Key: WFLY-2755
>                 URL: https://issues.jboss.org/browse/WFLY-2755
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.CR1
>
>
> For starters we need to split wildfly core out of WildFly repository.
> This needs to include moving tests that are related only to core, such as domain testsuite, patching....

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 05:30:33 2014
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 15 Jan 2014 05:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-971) Tests failing Intermittently
 on slow machines - XTS WSAT, WSBA
In-Reply-To: <JIRA.12471580.1343828178000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471580.1343828178000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471580.1343828178000.44507.1389781833426@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky resolved WFLY-971.
--------------------------------

    Resolution: Out of Date

    
> Tests failing Intermittently on slow machines - XTS WSAT, WSBA
> --------------------------------------------------------------
>
>                 Key: WFLY-971
>                 URL: https://issues.jboss.org/browse/WFLY-971
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ivo Studensky
>
> These tests fail intermintently on really slow machines.
> To reproduce, try to run in EC2 on 32-bit "small" instance type.
> https://jenkins-jbossqa.rhcloud.com/job/EAP6-EC2/
> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase.testCommit
> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase.testRollback
> org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase.testSuccess
> org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase.testCancel
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.testSuccess
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.testCancel 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 05:32:32 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jan 2014 05:32:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2756) Default connector is
 hardcoded in JMS connection factory definition
In-Reply-To: <JIRA.12529472.1389781859930@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529472.1389781859930@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529472.1389781859930.44509.1389781952811@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2756:
---------------------------------

             Summary: Default connector is hardcoded in JMS connection factory definition
                 Key: WFLY-2756
                 URL: https://issues.jboss.org/browse/WFLY-2756
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Critical
             Fix For: 8.0.0.Final


When JMS connection factory definitions are used to setup connection factory, the messaging subsystem adds the "netty" connector if no connectors are specified in the definition.

This introduces a problem if users do not define a connector named "netty" in their configuration (as it will be the case when we switch to using the http-connector instead of the remote-connector by default).

Workaround this is to ask HornetQ for the connectors that can be used and pick one (and logs a warning message telling the user that it should not depend on that behaviour and explicitly specify which connector to use).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 05:32:33 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jan 2014 05:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2730) HTTP upgrade does not accept
 multiple acceptors
In-Reply-To: <JIRA.12528997.1389278853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528997.1389278853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528997.1389278853000.44515.1389781953279@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2730:
------------------------------

    Priority: Critical  (was: Major)

    
> HTTP upgrade does not accept multiple acceptors
> -----------------------------------------------
>
>                 Key: WFLY-2730
>                 URL: https://issues.jboss.org/browse/WFLY-2730
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> The http-acceptors are multiplexed over the HTTP port.
> If there are multiple http-acceptors registered, a http-connector that uses the HTTP upgrade mechanism will use the first whose handshake is successful and can not chose a given http-acceptor.
> With native messaging ports, the solution was to use different ports for different acceptors but with HTTP upgrade, everything goes through the HTTP port.
> HornetQ connectors must pass "http-upgrade-endpoint" when the HTTP upgrade is initiated so that we ensure the handshake is successful only for the matching acceptor corresponding to the "http-upgrade-endpoint" 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 issues at jboss.org  Wed Jan 15 06:10:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 06:10:33 -0500 (EST)
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.44671.1389784233290@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935842#comment-12935842 ] 

RH Bugzilla Integration commented on WFLY-1701:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 984855|https://bugzilla.redhat.com/show_bug.cgi?id=984855] from POST to MODIFIED
                
> 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
>      Security Level: Public(Everyone can see) 
>          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.Final
>
>
> 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 issues at jboss.org  Wed Jan 15 06:14:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 06:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.44679.1389784472848@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935843#comment-12935843 ] 

RH Bugzilla Integration commented on WFLY-1594:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 976917|https://bugzilla.redhat.com/show_bug.cgi?id=976917] from POST to MODIFIED
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 06:16:33 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 15 Jan 2014 06:16:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.44690.1389784593766@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935846#comment-12935846 ] 

Stefano Maestri commented on WFLY-2749:
---------------------------------------

are you using it in standalone/domain, or is it a -ds.xml file?
                
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>            Assignee: Stefano Maestri
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 06:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 06:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree
 viewer does not work with timer and || operator.
In-Reply-To: <JIRA.12518034.1383664067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518034.1383664067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518034.1383664067000.44698.1389785553229@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935847#comment-12935847 ] 

RH Bugzilla Integration commented on DROOLS-320:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1027118|https://bugzilla.redhat.com/show_bug.cgi?id=1027118] from MODIFIED to VERIFIED
                
> Drools plugin Rete Tree viewer does not work with timer and || operator.
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-320
>                 URL: https://issues.jboss.org/browse/DROOLS-320
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>         Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>              Labels: drools, eclipse, plugin, rete, tree, view
>
> See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
> The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
> - the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException: [Rete(0)]
> - the '||' operator in the rule "Hello World-Or". This gives the error:
> Rete Tree Build Error!
> Reason:
> java.lang.NullPointerException: null
> This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 06:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 06:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree
 viewer does not work with timer and || operator.
In-Reply-To: <JIRA.12518034.1383664067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518034.1383664067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518034.1383664067000.44703.1389785553663@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935848#comment-12935848 ] 

RH Bugzilla Integration commented on DROOLS-320:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1027120|https://bugzilla.redhat.com/show_bug.cgi?id=1027120] from MODIFIED to VERIFIED
                
> Drools plugin Rete Tree viewer does not work with timer and || operator.
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-320
>                 URL: https://issues.jboss.org/browse/DROOLS-320
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>         Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>              Labels: drools, eclipse, plugin, rete, tree, view
>
> See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
> The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
> - the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException: [Rete(0)]
> - the '||' operator in the rule "Hello World-Or". This gives the error:
> Rete Tree Build Error!
> Reason:
> java.lang.NullPointerException: null
> This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 06:32:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Jan 2014 06:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree
 viewer does not work with Conditional Named Consequence expressions
In-Reply-To: <JIRA.12518194.1383779130000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518194.1383779130000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518194.1383779130000.44706.1389785553914@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935849#comment-12935849 ] 

RH Bugzilla Integration commented on DROOLS-326:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1027765|https://bugzilla.redhat.com/show_bug.cgi?id=1027765] from MODIFIED to VERIFIED
                
> Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-326
>                 URL: https://issues.jboss.org/browse/DROOLS-326
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>         Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45
>            Reporter: Duncan Doyle
>            Assignee: Kris Verlaenen
>              Labels: conditional, consequence, eclipse, named, plugin, rete, tree, view
>             Fix For: 6.0.1.Final
>
>
> See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue
> The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException : [Rete(0)]
> And the Rete Tree is not displayed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 06:38:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 15 Jan 2014 06:38:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering-monitor
	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.44715.1389785913371@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-1430:
---------------------------------

    Summary: Create clustering-monitor subsystem  (was: Create clustering subsystem)

    
> Create clustering-monitor subsystem
> -----------------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          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 issues at jboss.org  Wed Jan 15 07:55:33 2014
From: issues at jboss.org (Markus Tippmann (JIRA))
Date: Wed, 15 Jan 2014 07:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-402) Programmatic rule update
	fails
In-Reply-To: <JIRA.12529486.1389790486385@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529486.1389790486385@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529486.1389790486385.44931.1389790533244@jira02.app.mwc.hst.phx2.redhat.com>

Markus Tippmann created DROOLS-402:
--------------------------------------

             Summary: Programmatic rule update fails
                 Key: DROOLS-402
                 URL: https://issues.jboss.org/browse/DROOLS-402
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final
         Environment: Windows 7
            Reporter: Markus Tippmann
            Assignee: Mark Proctor
         Attachments: drools.test.zip

Programmatic construction of a kmodule and updating its rules fails with different problems. 

I attach a small Maven project which runs 3 tests (one succeeds just for demonstration). I hope I'm doing correctly here on kmodule construction.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 07:55:33 2014
From: issues at jboss.org (Markus Tippmann (JIRA))
Date: Wed, 15 Jan 2014 07:55:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-402) Programmatic rule update
	fails
In-Reply-To: <JIRA.12529486.1389790486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529486.1389790486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529486.1389790486000.44933.1389790533350@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Markus Tippmann updated DROOLS-402:
-----------------------------------

    Attachment: drools.test.zip

    
> Programmatic rule update fails
> ------------------------------
>
>                 Key: DROOLS-402
>                 URL: https://issues.jboss.org/browse/DROOLS-402
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Windows 7
>            Reporter: Markus Tippmann
>            Assignee: Mark Proctor
>         Attachments: drools.test.zip
>
>
> Programmatic construction of a kmodule and updating its rules fails with different problems. 
> I attach a small Maven project which runs 3 tests (one succeeds just for demonstration). I hope I'm doing correctly here on kmodule construction.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 08:03:32 2014
From: issues at jboss.org (Marek Schmidt (JIRA))
Date: Wed, 15 Jan 2014 08:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2757) CNFE if sub-deployment (WAR
 in an EAR) depending on a static module with CDI portable extension
In-Reply-To: <JIRA.12529487.1389790917355@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529487.1389790917355@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529487.1389790917355.44948.1389791012980@jira02.app.mwc.hst.phx2.redhat.com>

Marek Schmidt created WFLY-2757:
-----------------------------------

             Summary: CNFE if sub-deployment (WAR in an EAR) depending on a static module with CDI portable extension
                 Key: WFLY-2757
                 URL: https://issues.jboss.org/browse/WFLY-2757
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
            Reporter: Marek Schmidt
            Assignee: Stuart Douglas


Having an EAR with an WAR depending on a CDI portable extension from a static module.

{code}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<!-- uncomment this and it will start to work
<deployment>
  <dependencies>
    <module name="org.jboss.test.extensionModule" />
  </dependencies>
</deployment>  -->

<sub-deployment name="test-web.war">
  <dependencies>
    <module name="org.jboss.test.extensionModule" meta-inf="import" services="import"/>
  </dependencies>
</sub-deployment>
{code}


causes an exception when a servlet from the test-web.war is accessed.

Adding the dependency to static module from the EAR itself (see above) will make this work, but this shouldn't be needed IMHO.

{quote}
13:51:56,069 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /test-web/funny: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.tests.module.extension.FunnyServlet
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:201) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
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.constructComponentInstance(BasicComponent.java:133)
	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1099)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:199) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
	... 25 more
Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Extension [class org.jboss.weld.tests.module.extension.FunExtension] with qualifiers [@Default]; test-web.war with class class org.jboss.weld.tests.module.extension.FunExtension using classloader ModuleClassLoader for Module "deployment.test.ear:main" from Service Module Loader
	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:326) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:277) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:111) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:181) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyProvider.access$100(ClientProxyProvider.java:45) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:56) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
	at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
	at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:80) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:205) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
	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:56) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
	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.CR1.jar:8.0.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
	... 30 more
Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:434) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:319) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	... 75 more
Caused by: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45]
	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) [:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
	... 77 more
Caused by: java.lang.ClassNotFoundException: org.jboss.weld.tests.module.extension.FunExtension from [Module "deployment.test.ear:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
	... 84 more
{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 issues at jboss.org  Wed Jan 15 08:03:33 2014
From: issues at jboss.org (Marek Schmidt (JIRA))
Date: Wed, 15 Jan 2014 08:03:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2757) CNFE if sub-deployment (WAR
 in an EAR) depending on a static module with CDI portable extension
In-Reply-To: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529487.1389790917000.44950.1389791013142@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Schmidt updated WFLY-2757:
--------------------------------

    Attachment: WFLY-2757.tar

    
> CNFE if sub-deployment (WAR in an EAR) depending on a static module with CDI portable extension
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2757
>                 URL: https://issues.jboss.org/browse/WFLY-2757
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: WFLY-2757.tar
>
>
> Having an EAR with an WAR depending on a CDI portable extension from a static module.
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <!-- uncomment this and it will start to work
> <deployment>
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" />
>   </dependencies>
> </deployment>  -->
> <sub-deployment name="test-web.war">
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" meta-inf="import" services="import"/>
>   </dependencies>
> </sub-deployment>
> {code}
> causes an exception when a servlet from the test-web.war is accessed.
> Adding the dependency to static module from the EAR itself (see above) will make this work, but this shouldn't be needed IMHO.
> {quote}
> 13:51:56,069 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /test-web/funny: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.tests.module.extension.FunnyServlet
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:201) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 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.constructComponentInstance(BasicComponent.java:133)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1099)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:199) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	... 25 more
> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Extension [class org.jboss.weld.tests.module.extension.FunExtension] with qualifiers [@Default]; test-web.war with class class org.jboss.weld.tests.module.extension.FunExtension using classloader ModuleClassLoader for Module "deployment.test.ear:main" from Service Module Loader
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:326) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:277) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:111) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:181) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.access$100(ClientProxyProvider.java:45) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:56) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> 	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> 	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> 	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> 	at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> 	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
> 	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:80) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:205) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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:56) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
> 	... 30 more
> Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:434) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:319) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 75 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45]
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) [:1.7.0_45]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 77 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.weld.tests.module.extension.FunExtension from [Module "deployment.test.ear:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> 	... 84 more
> {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 issues at jboss.org  Wed Jan 15 08:05:32 2014
From: issues at jboss.org (Marek Schmidt (JIRA))
Date: Wed, 15 Jan 2014 08:05:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2757) CNFE if sub-deployment (WAR
 in an EAR) depending on a static module with CDI portable extension
In-Reply-To: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529487.1389790917000.44957.1389791132949@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Schmidt updated WFLY-2757:
--------------------------------

    Steps to Reproduce: 
1. untar the reproducer WFLY-2757.tar
2. put the org/  (containing a org/jboss/test/extensionModule/main/  module) to the modules/ directory
3. deploy the test.ear
4. open http://127.0.0.1:8080/test-web/funny

Notice the error. 

it should say 

"Number of funny beans: 1
funny bean: class org.jboss.weld.tests.module.extension.Clown"

    
> CNFE if sub-deployment (WAR in an EAR) depending on a static module with CDI portable extension
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2757
>                 URL: https://issues.jboss.org/browse/WFLY-2757
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: WFLY-2757.tar
>
>
> Having an EAR with an WAR depending on a CDI portable extension from a static module.
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <!-- uncomment this and it will start to work
> <deployment>
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" />
>   </dependencies>
> </deployment>  -->
> <sub-deployment name="test-web.war">
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" meta-inf="import" services="import"/>
>   </dependencies>
> </sub-deployment>
> {code}
> causes an exception when a servlet from the test-web.war is accessed.
> Adding the dependency to static module from the EAR itself (see above) will make this work, but this shouldn't be needed IMHO.
> {quote}
> 13:51:56,069 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /test-web/funny: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.tests.module.extension.FunnyServlet
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:201) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 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.constructComponentInstance(BasicComponent.java:133)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1099)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:199) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	... 25 more
> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Extension [class org.jboss.weld.tests.module.extension.FunExtension] with qualifiers [@Default]; test-web.war with class class org.jboss.weld.tests.module.extension.FunExtension using classloader ModuleClassLoader for Module "deployment.test.ear:main" from Service Module Loader
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:326) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:277) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:111) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:181) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.access$100(ClientProxyProvider.java:45) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:56) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> 	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> 	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> 	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> 	at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> 	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
> 	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:80) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:205) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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:56) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
> 	... 30 more
> Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:434) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:319) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 75 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45]
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) [:1.7.0_45]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 77 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.weld.tests.module.extension.FunExtension from [Module "deployment.test.ear:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> 	... 84 more
> {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 issues at jboss.org  Wed Jan 15 09:33:33 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Jan 2014 09:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.45109.1389796413366@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2753:
-----------------------------

    Assignee: Kyle Lape  (was: Kabir Khan)

    
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 09:33:33 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Jan 2014 09:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.45112.1389796413634@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-2753.
------------------------------

    Resolution: Done

    
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 09:33:33 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Jan 2014 09:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.45115.1389796413894@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-2753.
----------------------------


    
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 09:43:33 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 15 Jan 2014 09:43:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2757) CNFE if sub-deployment (WAR
 in an EAR) depending on a static module with CDI portable extension
In-Reply-To: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529487.1389790917000.45199.1389797013871@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935935#comment-12935935 ] 

Stuart Douglas commented on WFLY-2757:
--------------------------------------

The issue is in how we select the class loader to create the proxy. Normally we use the class loader of the class that is being proxied, however we cannot do that in this case because the class is in a static module, and defining the proxy there would cause a class loader leak (and probably just plain fail to work, depending on if the module has dependencies the proxy needs).

Because we cannot use the static modules class loader instead we always use the class loader of the top level deployment, which in this case is the ears class loader.

We don't really have any way to tell that the Servlet class loader is the class loader that we should be using. Even though it seems obvious in this case, it is possible to get much more complex scenarios where it is not obvious. For example what if your ear has two wars that each have a dependency? We would basically have to pick one at random. Basically any logic we added in this area would just be guessing, and I would rather avoid that. 

[~jharting] Do we actually need to create a proxy for an extension? The instance is going to be the same throughout, so I wonder if we could just inject the instance directly. I have a feeling that there is some reason why we can't but I can't remember what that reason is off the top of my head. 
                
> CNFE if sub-deployment (WAR in an EAR) depending on a static module with CDI portable extension
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2757
>                 URL: https://issues.jboss.org/browse/WFLY-2757
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: WFLY-2757.tar
>
>
> Having an EAR with an WAR depending on a CDI portable extension from a static module.
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <!-- uncomment this and it will start to work
> <deployment>
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" />
>   </dependencies>
> </deployment>  -->
> <sub-deployment name="test-web.war">
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" meta-inf="import" services="import"/>
>   </dependencies>
> </sub-deployment>
> {code}
> causes an exception when a servlet from the test-web.war is accessed.
> Adding the dependency to static module from the EAR itself (see above) will make this work, but this shouldn't be needed IMHO.
> {quote}
> 13:51:56,069 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /test-web/funny: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.tests.module.extension.FunnyServlet
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:201) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 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.constructComponentInstance(BasicComponent.java:133)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1099)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:199) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	... 25 more
> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Extension [class org.jboss.weld.tests.module.extension.FunExtension] with qualifiers [@Default]; test-web.war with class class org.jboss.weld.tests.module.extension.FunExtension using classloader ModuleClassLoader for Module "deployment.test.ear:main" from Service Module Loader
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:326) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:277) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:111) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:181) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.access$100(ClientProxyProvider.java:45) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:56) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> 	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> 	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> 	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> 	at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> 	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
> 	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:80) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:205) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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:56) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
> 	... 30 more
> Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:434) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:319) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 75 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45]
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) [:1.7.0_45]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 77 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.weld.tests.module.extension.FunExtension from [Module "deployment.test.ear:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> 	... 84 more
> {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 issues at jboss.org  Wed Jan 15 09:43:34 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 15 Jan 2014 09:43:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2757) CNFE if sub-deployment (WAR
 in an EAR) depending on a static module with CDI portable extension
In-Reply-To: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529487.1389790917000.45204.1389797014176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2757.
----------------------------------

    Resolution: Won't Fix

    
> CNFE if sub-deployment (WAR in an EAR) depending on a static module with CDI portable extension
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2757
>                 URL: https://issues.jboss.org/browse/WFLY-2757
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: WFLY-2757.tar
>
>
> Having an EAR with an WAR depending on a CDI portable extension from a static module.
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <!-- uncomment this and it will start to work
> <deployment>
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" />
>   </dependencies>
> </deployment>  -->
> <sub-deployment name="test-web.war">
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" meta-inf="import" services="import"/>
>   </dependencies>
> </sub-deployment>
> {code}
> causes an exception when a servlet from the test-web.war is accessed.
> Adding the dependency to static module from the EAR itself (see above) will make this work, but this shouldn't be needed IMHO.
> {quote}
> 13:51:56,069 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /test-web/funny: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.tests.module.extension.FunnyServlet
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:201) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 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.constructComponentInstance(BasicComponent.java:133)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1099)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:199) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	... 25 more
> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Extension [class org.jboss.weld.tests.module.extension.FunExtension] with qualifiers [@Default]; test-web.war with class class org.jboss.weld.tests.module.extension.FunExtension using classloader ModuleClassLoader for Module "deployment.test.ear:main" from Service Module Loader
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:326) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:277) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:111) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:181) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.access$100(ClientProxyProvider.java:45) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:56) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> 	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> 	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> 	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> 	at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> 	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
> 	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:80) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:205) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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:56) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
> 	... 30 more
> Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:434) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:319) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 75 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45]
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) [:1.7.0_45]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 77 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.weld.tests.module.extension.FunExtension from [Module "deployment.test.ear:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> 	... 84 more
> {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 issues at jboss.org  Wed Jan 15 09:43:34 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 15 Jan 2014 09:43:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.45210.1389797014446@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935938#comment-12935938 ] 

Stuart Douglas commented on WFLY-2751:
--------------------------------------

[~jharting] This also appears to be an issue caused by the weld filter eagerly parsing requests. 
                
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	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.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 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 issues at jboss.org  Wed Jan 15 09:56:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 15 Jan 2014 09:56:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2757) CNFE if sub-deployment (WAR
 in an EAR) depending on a static module with CDI portable extension
In-Reply-To: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529487.1389790917000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529487.1389790917000.45268.1389797793156@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935950#comment-12935950 ] 

Jozef Hartinger commented on WFLY-2757:
---------------------------------------

We need the proxy because of passivation.
                
> CNFE if sub-deployment (WAR in an EAR) depending on a static module with CDI portable extension
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2757
>                 URL: https://issues.jboss.org/browse/WFLY-2757
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: WFLY-2757.tar
>
>
> Having an EAR with an WAR depending on a CDI portable extension from a static module.
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <!-- uncomment this and it will start to work
> <deployment>
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" />
>   </dependencies>
> </deployment>  -->
> <sub-deployment name="test-web.war">
>   <dependencies>
>     <module name="org.jboss.test.extensionModule" meta-inf="import" services="import"/>
>   </dependencies>
> </sub-deployment>
> {code}
> causes an exception when a servlet from the test-web.war is accessed.
> Adding the dependency to static module from the EAR itself (see above) will make this work, but this shouldn't be needed IMHO.
> {quote}
> 13:51:56,069 ERROR [io.undertow.request] (default task-5) UT005023: Exception handling request to /test-web/funny: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.tests.module.extension.FunnyServlet
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:201) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 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.constructComponentInstance(BasicComponent.java:133)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:89)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1099)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:199) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> 	... 25 more
> Caused by: org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean Extension [class org.jboss.weld.tests.module.extension.FunExtension] with qualifiers [@Default]; test-web.war with class class org.jboss.weld.tests.module.extension.FunExtension using classloader ModuleClassLoader for Module "deployment.test.ear:main" from Service Module Loader
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:326) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:277) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:111) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:181) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.access$100(ClientProxyProvider.java:45) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:56) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider$CreateClientProxy.load(ClientProxyProvider.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> 	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> 	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> 	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> 	at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> 	at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3936)
> 	at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4806)
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:52) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:80) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:205) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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:56) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 	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.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
> 	... 30 more
> Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:101) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:434) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:319) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 75 more
> Caused by: java.lang.NoClassDefFoundError: org/jboss/weld/tests/module/extension/FunExtension
> 	at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45]
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) [:1.7.0_45]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> 	... 77 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.weld.tests.module.extension.FunExtension from [Module "deployment.test.ear:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
> 	... 84 more
> {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 issues at jboss.org  Wed Jan 15 10:34:33 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 15 Jan 2014 10:34:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.45446.1389800073713@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri resolved WFLY-2749.
-----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Out of Date


Already solved on current master
                
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 10:44:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 15 Jan 2014 10:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2749) Unable to parse
 no-tx-separate-pools element of xa-pool in datasource definition
In-Reply-To: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529231.1389625946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529231.1389625946000.45473.1389800673375@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935985#comment-12935985 ] 

Jesper Pedersen commented on WFLY-2749:
---------------------------------------

{noformat}
main/java/org/jboss/as/connector/subsystems/datasources/Constants.java:    private static final String NOTXSEPARATEPOOL_NAME = "no-tx-separate-pool";                                                              
main/java/org/jboss/as/connector/subsystems/resourceadapters/Constants.java:    private static final String NOTXSEPARATEPOOL_NAME = "no-tx-separate-pool";                                                         
{noformat}
                
> Unable to parse no-tx-separate-pools element of xa-pool in datasource definition
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2749
>                 URL: https://issues.jboss.org/browse/WFLY-2749
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: JBoss AS7 7.2.0.Final
>            Reporter: Kevin Formsma
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>
> Defining a XA datasource with a pool as below fails. This element is valid in the schema documentation. The connector system fails to parse this, as in org.jboss.as.connector.subsystems.datasources.Constants.java the tag is mistyped as "no-tx-separate-pool" without the "pools".
> {code:xml}
>         <xa-pool>
>             <no-tx-separate-pools/>
>         </xa-pool>
> {code}
> Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: no-tx-separate-pools
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXaPool(DsParser.java:551)
> 	at org.jboss.jca.common.metadata.ds.v11.DsParser.parseXADataSource(DsParser.java:162)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parseDataSources(DsParser.java:185)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:124)
> 	at org.jboss.jca.common.metadata.ds.v10.DsParser.parse(DsParser.java:87)
> 	at org.jboss.as.connector.deployers.ds.processors.DsXmlDeploymentParsingProcessor.deploy(DsXmlDeploymentParsingProcessor.java:86)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 11:00:33 2014
From: issues at jboss.org (Justin Bertram (JIRA))
Date: Wed, 15 Jan 2014 11:00:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2758) Support
 initial-connect-attempts for cluster-connection and bridge
In-Reply-To: <JIRA.12529509.1389801578070@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529509.1389801578070@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529509.1389801578070.45524.1389801633798@jira02.app.mwc.hst.phx2.redhat.com>

Justin Bertram created WFLY-2758:
------------------------------------

             Summary: Support initial-connect-attempts for cluster-connection and bridge
                 Key: WFLY-2758
                 URL: https://issues.jboss.org/browse/WFLY-2758
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Justin Bertram
            Assignee: Jeff Mesnil


HornetQ 2.4.1.Final will have a new parameter for cluster-connection and core bridge elements (via HORNETQ-1306).  This parameter is "initial-connect-attempts".  Please support this new parameter in the messaging 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 issues at jboss.org  Wed Jan 15 13:18:33 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 15 Jan 2014 13:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.45820.1389809913127@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936046#comment-12936046 ] 

Shelly McGowan commented on JBEE-133:
-------------------------------------

Preparing to push .Final release.  Any additional updates?
                
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.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 issues at jboss.org  Wed Jan 15 13:18:33 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 15 Jan 2014 13:18:33 -0500 (EST)
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.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501330.1379963000000.45824.1389809913281@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936048#comment-12936048 ] 

Shelly McGowan commented on JBEE-141:
-------------------------------------

I'd like to get the .Final release out in preparation for inclusion in WildFly 8.0.0.Final.   Are there more changes to commit to the https://github.com/jboss/jboss-jacc-api_spec repo?
                
> 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
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>
> 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 issues at jboss.org  Wed Jan 15 13:20:32 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 15 Jan 2014 13:20:32 -0500 (EST)
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.45829.1389810032916@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reopened JBEE-140:
---------------------------------



Preparing the .Final release of JASPIC APIs.  Are there any additional updates need before the release is done.
                
> 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: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta2
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> 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 issues at jboss.org  Wed Jan 15 17:12:32 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 15 Jan 2014 17:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1918) Introduce "version" to all
	operations
In-Reply-To: <JIRA.12474756.1347978678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474756.1347978678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474756.1347978678000.46014.1389823952906@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-1918:
------------------------------

    Priority: Blocker  (was: Major)

    
> Introduce "version" to all operations
> -------------------------------------
>
>                 Key: WFLY-1918
>                 URL: https://issues.jboss.org/browse/WFLY-1918
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> To better support backward compatibility for upcoming version of AS/mgmt api
> For start we should probably just send mgmt version of subsystem/core 
> in future we could use this info to route operations properly 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 15 17:16:34 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 15 Jan 2014 17:16:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1918) Introduce "version" to all
	operations
In-Reply-To: <JIRA.12474756.1347978678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474756.1347978678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474756.1347978678000.46023.1389824194951@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936090#comment-12936090 ] 

David Lloyd commented on WFLY-1918:
-----------------------------------

This must be solved for 9.x in my opinion.  It *should* be solved for 8.x but maybe we can work around it by bumping the protocol version and changing the "default" based on lowest agreed version #.
                
> Introduce "version" to all operations
> -------------------------------------
>
>                 Key: WFLY-1918
>                 URL: https://issues.jboss.org/browse/WFLY-1918
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> To better support backward compatibility for upcoming version of AS/mgmt api
> For start we should probably just send mgmt version of subsystem/core 
> in future we could use this info to route operations properly 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 03:32:32 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jan 2014 03:32:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2759) Upgrade to HornetQ 2.4.1.Final
In-Reply-To: <JIRA.12529562.1389861036088@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529562.1389861036088@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529562.1389861036088.46648.1389861152959@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2759:
---------------------------------

             Summary: Upgrade to HornetQ 2.4.1.Final
                 Key: WFLY-2759
                 URL: https://issues.jboss.org/browse/WFLY-2759
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Critical
             Fix For: 8.0.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 issues at jboss.org  Thu Jan 16 04:44:33 2014
From: issues at jboss.org (Jan Martiska (JIRA))
Date: Thu, 16 Jan 2014 04:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2760) Intermittent failure of
 ExternalContextBindingTestCase
In-Reply-To: <JIRA.12529570.1389865466788@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529570.1389865466788@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529570.1389865466788.46773.1389865473813@jira02.app.mwc.hst.phx2.redhat.com>

Jan Martiska created WFLY-2760:
----------------------------------

             Summary:  Intermittent failure of ExternalContextBindingTestCase
                 Key: WFLY-2760
                 URL: https://issues.jboss.org/browse/WFLY-2760
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.CR1
            Reporter: Jan Martiska
            Assignee: Jan Martiska
            Priority: Minor


The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.

It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 04:46:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 16 Jan 2014 04:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.46778.1389865593971@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2689:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Jozef Hartinger
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 04:46:34 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 16 Jan 2014 04:46:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.46786.1389865594807@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936214#comment-12936214 ] 

Jozef Hartinger commented on WFLY-2751:
---------------------------------------

You should be able to use the standard Servlet error handling mechanism to deal with the exception
                
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	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.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 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 issues at jboss.org  Thu Jan 16 04:46:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 04:46:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2760) Intermittent failure of
 ExternalContextBindingTestCase
In-Reply-To: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529570.1389865466000.46788.1389865595056@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2760:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1054106

    
>  Intermittent failure of ExternalContextBindingTestCase
> -------------------------------------------------------
>
>                 Key: WFLY-2760
>                 URL: https://issues.jboss.org/browse/WFLY-2760
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Minor
>
> The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.
> It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 05:10:32 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 16 Jan 2014 05:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2761) Make it possible for static
 cdi-enabled modules to see the beans in top-level deployments
In-Reply-To: <JIRA.12529575.1389867009756@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529575.1389867009756@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529575.1389867009756.46837.1389867032806@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2761:
-------------------------------------

             Summary: Make it possible for static cdi-enabled modules to see the beans in top-level deployments
                 Key: WFLY-2761
                 URL: https://issues.jboss.org/browse/WFLY-2761
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
            Priority: Critical
             Fix For: 8.0.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 issues at jboss.org  Thu Jan 16 05:20:33 2014
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Thu, 16 Jan 2014 05:20:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612897@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612897@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612897.46843.1389867633442@jira02.app.mwc.hst.phx2.redhat.com>

Gunnar Morling created WFLY-2762:
------------------------------------

             Summary: Injection of application-provided CDI bean into extension-provided bean fails
                 Key: WFLY-2762
                 URL: https://issues.jboss.org/browse/WFLY-2762
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
            Reporter: Gunnar Morling
            Assignee: Stuart Douglas


When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.

The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:

{quote}
WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
    at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
{quote}

A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:

{code}
mvn clean install -pl integration -Dit.test=InjectionIssueIT
{code}

The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 05:22:32 2014
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Thu, 16 Jan 2014 05:22:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.46846.1389867752865@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936226#comment-12936226 ] 

Gunnar Morling commented on WFLY-2762:
--------------------------------------

Discussed this issue with Jozef, he'll take a look.
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Stuart Douglas
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 05:26:34 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 16 Jan 2014 05:26:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.46862.1389867994000@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2762:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 05:30:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 16 Jan 2014 05:30:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2763) Limit Weld packages exported
 to deployments
In-Reply-To: <JIRA.12529577.1389868153604@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529577.1389868153604@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529577.1389868153604.46867.1389868233538@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2763:
-------------------------------------

             Summary: Limit Weld packages exported to deployments
                 Key: WFLY-2763
                 URL: https://issues.jboss.org/browse/WFLY-2763
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
             Fix For: 8.0.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 issues at jboss.org  Thu Jan 16 05:36:32 2014
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Thu, 16 Jan 2014 05:36:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.46891.1389868592776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936236#comment-12936236 ] 

Gunnar Morling commented on WFLY-2762:
--------------------------------------

Some more things which may be helpful:

* The PE lives [here|https://github.com/hibernate/hibernate-validator/tree/master/cdi] (contains {{ValidationExtension}}, {{ValidationInterceptor}} etc.)
* When executing the test via Maven, WF 8.0.0.CR1 will be extracted into the target directory, and the module for HV and the PE will be updated with the current snapshot version
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 05:38:33 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jan 2014 05:38:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2764) clean up use of deprecated
 description in messaging subsystem
In-Reply-To: <JIRA.12529579.1389868598877@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529579.1389868598877@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529579.1389868598877.46897.1389868713052@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2764:
---------------------------------

             Summary: clean up use of deprecated description in messaging subsystem
                 Key: WFLY-2764
                 URL: https://issues.jboss.org/browse/WFLY-2764
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Minor
             Fix For: 9.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 issues at jboss.org  Thu Jan 16 05:40:32 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jan 2014 05:40:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2608) MDB not receiving messages
	from JMS queue.
In-Reply-To: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526998.1386191721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526998.1386191721000.46906.1389868832938@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2608:
------------------------------

    Priority: Major  (was: Blocker)

    
> MDB not receiving messages from JMS queue.
> ------------------------------------------
>
>                 Key: WFLY-2608
>                 URL: https://issues.jboss.org/browse/WFLY-2608
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Corey Puffalt
>            Assignee: Jeff Mesnil
>
> We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB.  The forum thread referenced below has more background information but basically at some point we see the following in our server logs:
> {code}
> 00:50:28,915 WARN  [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
> 00:50:29,208 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> 00:50:29,235 WARN  [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> [the above two messages are repeated a number of times in rapid succession...and then finally we get...]
> 00:50:30,187 WARN  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:29,240 WARN  [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:38,633 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> 00:50:38,636 INFO  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> {code}
> After this our MDB never receives any further messages until a server restart.  HornetQ should be recovering from this situation (whatever the cause).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 05:40:33 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jan 2014 05:40:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2443) JMS service shutsdown and
 doesn't recover after disk fills up.
In-Reply-To: <JIRA.12518063.1383674928000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518063.1383674928000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518063.1383674928000.46910.1389868833308@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2443:
------------------------------

    Priority: Major  (was: Critical)

    
> JMS service shutsdown and doesn't recover after disk fills up.
> --------------------------------------------------------------
>
>                 Key: WFLY-2443
>                 URL: https://issues.jboss.org/browse/WFLY-2443
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>         Environment: RHEL 5.2
> JDK 1.7.0_07
>            Reporter: Corey Puffalt
>            Assignee: Jeff Mesnil
>
> In AS 7.1.2 we had a disk fill up and we see warnings (not an error??):
> {code}
> 06:07:40,641 WARNING [org.hornetq.core.server.impl.HornetQServerImpl] (Thread-1973 (HornetQ-remoting-threads-HornetQServerImpl::serverUUID=d7fd8a09-5f3c-11e2-a072-49b352663c05-1554718086-1713338353)) Critical IO Error, shutting down the server. code=6, message=No space left on device
> 06:07:40,892 WARN  [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (Thread-15478 (HornetQ-client-global-threads-251718996)) Connection failure has been detected: The connection was disconnected because of server shutdown [code=4]
> 06:07:40,893 WARN  [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-15478 (HornetQ-client-global-threads-251718996)) being disconnected for server shutdown: HornetQException[errorCode=4 message=The connection was disconnected because of server shutdown]
>         at org.hornetq.core.client.impl.ClientSessionFactoryImpl$Channel0Handler$1.run(ClientSessionFactoryImpl.java:1468) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> {code}
> After the disk space issue was resolved JMS services didn't recover (though we didn't notice this for awhile) so we didn't restart JBoss as we didn't realize there was an issue.  In checking the logs after the fact we see periodic warnings (again, it seems strange this is just a warning instead of an error):
> {code}
> 08:28:51,564 WARN  [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Periodic Recovery) Can't connect to XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] on auto-generated resource recovery: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]
>         at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:774) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:347) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:262) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:76) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.4.Final.jar:]
> 08:28:51,646 WARN  [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Periodic Recovery) Can't connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]]
> 08:28:51,647 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:76) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.4.Final.jar:]
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.4.Final.jar:]
> Caused by: HornetQException[errorCode=2 message=null]
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:396) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:262) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
>         ... 7 more
> {code}
> It seems if the whole server process isn't going to shutdown when the disk fills up then services like JMS should just reject messages if the disk fills up rather than shutting down.  That way services nicely recover as soon as there's disk space again.  The way it is currently, it's easy to miss that JBoss is only partially inoperable.
> Thanks,
> Corey

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 06:06:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 06:06:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.46986.1389870392975@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936249#comment-12936249 ] 

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from POST to MODIFIED
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Thu Jan 16 06:06:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 06:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.46989.1389870393233@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936250#comment-12936250 ] 

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1050225|https://bugzilla.redhat.com/show_bug.cgi?id=1050225] from POST to MODIFIED
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 06:14:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 06:14:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.47024.1389870872698@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936253#comment-12936253 ] 

RH Bugzilla Integration commented on WFLY-2753:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1053355|https://bugzilla.redhat.com/show_bug.cgi?id=1053355] from NEW to MODIFIED
                
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 06:30:34 2014
From: issues at jboss.org (Gary Brown (JIRA))
Date: Thu, 16 Jan 2014 06:30:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-403) Use of drools karaf feature
 required activated bundle to import drools packages
In-Reply-To: <JIRA.12529589.1389871804150@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529589.1389871804150@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529589.1389871804150.47059.1389871834039@jira02.app.mwc.hst.phx2.redhat.com>

Gary Brown created DROOLS-403:
---------------------------------

             Summary: Use of drools karaf feature required activated bundle to import drools packages
                 Key: DROOLS-403
                 URL: https://issues.jboss.org/browse/DROOLS-403
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR5
            Reporter: Gary Brown
            Assignee: Mark Proctor


Currently porting rtgov to Karaf, which uses Drools as one of the event processor implementations, using the KIE API: https://github.com/Governance/rtgov/blob/master/modules/event-processor/ep-drools/src/main/java/org/overlord/rtgov/ep/drools/DroolsEventProcessor.java

When the bundle is activated, that registers the event processor, its drools rule and associated user defined classes, etc, it results in class loading issues if the following packages are not defined in the Import-Package of the activated (i.e. client) bundle:

org.drools.core.conflict,org.drools.core.rule.builder.dialect.asm,org.drools.core.spi,org.drools.core.reteoo,org.drools.core,org.drools.core.common,org.drools.core.rule

The exceptions occur when the drools classes are being loaded via the ProjectClassLoader class. Ideally client bundles should only be importing the kie packages, as the drools classes should be internal implementation details.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 06:52:33 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Thu, 16 Jan 2014 06:52:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2441) Make Servlet container the
 default in Arquillian WildFly
In-Reply-To: <JIRA.12518018.1383655249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518018.1383655249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518018.1383655249000.47087.1389873153189@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko reassigned WFLY-2441:
---------------------------------

    Assignee: Karel Piwko  (was: Ondrej Zizka)

    
> Make Servlet container the default in Arquillian WildFly
> --------------------------------------------------------
>
>                 Key: WFLY-2441
>                 URL: https://issues.jboss.org/browse/WFLY-2441
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Karel Piwko
>            Assignee: Karel Piwko
>            Priority: Critical
>
> Current setting of jmx-as7 as default protocol complicated setup for consumers of Arquillian platform.
> JMX-AS7 protocol should be used for testing container implementation, not for testing applications deployed on WildFly. 
> For that reason, WildFly testsuite should be the place where protocol is overridden to jmx-as7, not the other way 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 issues at jboss.org  Thu Jan 16 07:42:33 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jan 2014 07:42:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2736) IronJacamar 1.1.3.Final
In-Reply-To: <JIRA.12529110.1389366189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529110.1389366189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529110.1389366189000.47178.1389876153185@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved WFLY-2736.
-----------------------------------

    Resolution: Done

    
> IronJacamar 1.1.3.Final
> -----------------------
>
>                 Key: WFLY-2736
>                 URL: https://issues.jboss.org/browse/WFLY-2736
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 8.0.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 issues at jboss.org  Thu Jan 16 08:26:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 16 Jan 2014 08:26:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2448) Print IOR to a user specified
	file
In-Reply-To: <JIRA.12518153.1383748388000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518153.1383748388000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518153.1383748388000.47291.1389878792984@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936285#comment-12936285 ] 

Stuart Douglas commented on WFLY-2448:
--------------------------------------

This should be done through the management API rather than using a system property.
                
> Print IOR to a user specified file
> ----------------------------------
>
>                 Key: WFLY-2448
>                 URL: https://issues.jboss.org/browse/WFLY-2448
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: IIOP
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows, Solaris, Linux
>            Reporter: Sumanth M S
>            Assignee: Stefan Guilhen
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>         Attachments: WFLY-2448.patch
>
>
> Jboss AS prints Corba IOR on console or log file. Many applications look for a file at a predefined location from where it can read the IOR; as it is difficult to read IOR programatically from a log file or console.
> An environment variable can be defined in standalone.conf to let the user specify the file location to which JBoss will print the IOR along with printing on the console.
> The solution has been tried and seems working. Please let us know if the solution can be submitted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 08:36:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Thu, 16 Jan 2014 08:36:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.47364.1389879393036@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936290#comment-12936290 ] 

Andre Pankraz commented on WFLY-2751:
-------------------------------------

I think you cannot really use this error handling mechanism in practice...because a RuntimeException in thrown which wraps an IOException (which both is by the way against the spec, that tells something about IllegalArgumentException - but I'm not a spec expert, just seen in the doc about Servlet 3).

Now you want to catch exception-class RuntimeException in web.xml and then what?
How many different cases will this handler catch? How will you inform the user (yes, those strange guys we write the web apps for...) will be informed? With a global error page outside of the original JSF page context?

Yes I can find workarounds, I can write a filter which catches those exceptions, inspects IOException with the proper message, then sets an attribute and I can check in the JSF controller etc. - which all is terrible - I would be faster to write a custom upload component and even would have a better architecture.

This shouldn't really be the final answer. Right now this new JSF 2.2 feature is totally unusable on Wildfly.
The overeager Welf-Filter also creates many other problems, like with error pages (no conversatzion conexts...), with setting encodings etc.
                
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	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.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 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 issues at jboss.org  Thu Jan 16 09:02:33 2014
From: issues at jboss.org (Ondrej Zizka (JIRA))
Date: Thu, 16 Jan 2014 09:02:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2427) Launcher API
In-Reply-To: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509240.1383251005000.47454.1389880953269@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936307#comment-12936307 ] 

Ondrej Zizka commented on WFLY-2427:
------------------------------------

Arquillian's command construction: https://github.com/wildfly/wildfly/blob/master/arquillian/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java
                
> Launcher API
> ------------
>
>                 Key: WFLY-2427
>                 URL: https://issues.jboss.org/browse/WFLY-2427
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. 
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. 
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -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 "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.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 issues at jboss.org  Thu Jan 16 09:10:32 2014
From: issues at jboss.org (Ondrej Zizka (JIRA))
Date: Thu, 16 Jan 2014 09:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2765) Incremental redeployment
 (single file update) over management API
In-Reply-To: <JIRA.12529602.1389881389025@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529602.1389881389025@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529602.1389881389025.47469.1389881432745@jira02.app.mwc.hst.phx2.redhat.com>

Ondrej Zizka created WFLY-2765:
----------------------------------

             Summary: Incremental redeployment (single file update) over management API
                 Key: WFLY-2765
                 URL: https://issues.jboss.org/browse/WFLY-2765
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: 8.0.0.CR1
            Reporter: Ondrej Zizka
             Fix For: 9.0.0.CR1


(Based on JBDS use case - see EAP6-1)
See also https://mojo.redhat.com/docs/DOC-934058 for notes

By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc.

Use cases:
      Big .war's, mainly on remote
      Cloud deployments
      Also, you loose sessions etc.

"JSP recompile on file update" - mgmt API operation - added in WildFly 8?

Not expected to work in domain mode.

Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 09:14:33 2014
From: issues at jboss.org (Ondrej Zizka (JIRA))
Date: Thu, 16 Jan 2014 09:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2766) .jar's on "current runtime
	classpath"
In-Reply-To: <JIRA.12529603.1389881603261@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529603.1389881603261@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529603.1389881603261.47482.1389881673072@jira02.app.mwc.hst.phx2.redhat.com>

Ondrej Zizka created WFLY-2766:
----------------------------------

             Summary: .jar's on "current runtime classpath"
                 Key: WFLY-2766
                 URL: https://issues.jboss.org/browse/WFLY-2766
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Class Loading, CLI
    Affects Versions: 8.0.0.CR1
            Reporter: Ondrej Zizka
            Assignee: David Lloyd
             Fix For: 9.0.0.CR1


(Based on JBDS use case - see EAP6-1)

In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
The classpath would be:

* for the deployment after deployed
* for a generic deployment if it was deployed right now - what would WildFly use?
* for the deployment before deployed - sounds a bit advanced but technically 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 issues at jboss.org  Thu Jan 16 09:18:32 2014
From: issues at jboss.org (Ondrej Zizka (JIRA))
Date: Thu, 16 Jan 2014 09:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2766) .jar's on "current runtime
	classpath"
In-Reply-To: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529603.1389881603000.47494.1389881912811@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Zizka updated WFLY-2766:
-------------------------------

    Description: 
(Based on JBDS use case - see EAP6-1)

In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )

The classpath would be:
* for the deployment after deployed
* for a generic deployment if it was deployed right now - what would WildFly use?
* for the deployment before deployed - sounds a bit advanced but technically possible

We (David, Stuart, Jason, Max, Ondra)  have discussed this on EAP F2F 2014.
The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".

The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.

  was:
(Based on JBDS use case - see EAP6-1)

In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
The classpath would be:

* for the deployment after deployed
* for a generic deployment if it was deployed right now - what would WildFly use?
* for the deployment before deployed - sounds a bit advanced but technically possible




    
> .jar's on "current runtime classpath"
> -------------------------------------
>
>                 Key: WFLY-2766
>                 URL: https://issues.jboss.org/browse/WFLY-2766
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ondrej Zizka
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra)  have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 09:30:32 2014
From: issues at jboss.org (Ondrej Zizka (JIRA))
Date: Thu, 16 Jan 2014 09:30:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2767) .cli files for pre/post-deploy
In-Reply-To: <JIRA.12529605.1389882555568@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529605.1389882555568@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529605.1389882555568.47529.1389882632944@jira02.app.mwc.hst.phx2.redhat.com>

Ondrej Zizka created WFLY-2767:
----------------------------------

             Summary:  .cli files for pre/post-deploy
                 Key: WFLY-2767
                 URL: https://issues.jboss.org/browse/WFLY-2767
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CLI
            Reporter: Ondrej Zizka
            Assignee: Alexey Loubyansky


(Based on JBDS use case - see EAP6-1)

There could be a pre/post-deploy.cli and pre/post-undeploy.cli in the deployed archive, and the server could perform these CLI scripts on respective events.

We (David, Stuart, Jason, Max, Ondra) have discussed this on EAP F2F 2014.
The preliminar outcome was "no way" - because the deploying itself is a management operation, and you can't do another operation during that.

Still, I'm adding this issue for the sake of completness of the ESSC-20 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 issues at jboss.org  Thu Jan 16 09:56:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 09:56:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-153) Fix logging of "Standard
 expiration of session X failed;
 switching to a brute force cleanup. Problem is null"
In-Reply-To: <JIRA.12467646.1338383878000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467646.1338383878000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467646.1338383878000.47591.1389884192920@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936327#comment-12936327 ] 

RH Bugzilla Integration commented on WFLY-153:
----------------------------------------------

Radoslav Husar <rhusar at redhat.com> changed the Status of [bug 900552|https://bugzilla.redhat.com/show_bug.cgi?id=900552] from NEW to POST
                
> Fix logging of "Standard expiration of session X failed; switching to a brute force cleanup. Problem is null"
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-153
>                 URL: https://issues.jboss.org/browse/WFLY-153
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha2
>
>
> I am seeing exception with missing reason
> {noformat}
> 19:54:12,862 WARN  [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session 7TYWbrkMf6UGi4WUu2Z3VUam failed; switching to a brute force cleanup. Problem is null
> {noformat}
> Looks like the actual exception is not well propagated to the message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:00:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 10:00:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.47618.1389884433828@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936334#comment-12936334 ] 

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from POST to MODIFIED
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:00:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 10:00:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.47623.1389884434207@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936335#comment-12936335 ] 

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from POST to MODIFIED
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Thu Jan 16 10:04:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 10:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.47666.1389884672755@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936350#comment-12936350 ] 

RH Bugzilla Integration commented on WFLY-2753:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1053382|https://bugzilla.redhat.com/show_bug.cgi?id=1053382] from NEW to MODIFIED
                
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:10:32 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 16 Jan 2014 10:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2767) .cli files for pre/post-deploy
In-Reply-To: <JIRA.12529605.1389882555000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529605.1389882555000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529605.1389882555000.47674.1389885032924@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-2767.
-------------------------------

    Resolution: Rejected


As discussed, it is not appropriate to mix CLI tasks with deployment tasks.  If this is desired for specific cases, we can evaluate each case to see if we have already created a solution for that case.
                
>  .cli files for pre/post-deploy
> -------------------------------
>
>                 Key: WFLY-2767
>                 URL: https://issues.jboss.org/browse/WFLY-2767
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Ondrej Zizka
>            Assignee: Alexey Loubyansky
>
> (Based on JBDS use case - see EAP6-1)
> There could be a pre/post-deploy.cli and pre/post-undeploy.cli in the deployed archive, and the server could perform these CLI scripts on respective events.
> We (David, Stuart, Jason, Max, Ondra) have discussed this on EAP F2F 2014.
> The preliminar outcome was "no way" - because the deploying itself is a management operation, and you can't do another operation during that.
> Still, I'm adding this issue for the sake of completness of the ESSC-20 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 issues at jboss.org  Thu Jan 16 10:12:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 10:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1339) Expose mod_cluster operations
 when running in domain mode
In-Reply-To: <JIRA.12491774.1368546393000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491774.1368546393000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491774.1368546393000.47676.1389885152831@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-1339.
--------------------------------

    Resolution: Rejected


Actually, this was reported via forums, but it actually works, all operations are there.

{code}
[domain at localhost:9990 /] /host=master/server=server-three/subsystem=modcluster:
add-proxy                   list-proxies                read-operation-description  read-resource-description   stop-context                
disable                     read-attribute              read-operation-names        refresh                     undefine-attribute          
disable-context             read-children-names         read-proxies-configuration  remove-proxy                write-attribute             
enable                      read-children-resources     read-proxies-info           reset                       
enable-context              read-children-types         read-resource               stop
{code}      
                
> Expose mod_cluster operations when running in domain mode
> ---------------------------------------------------------
>
>                 Key: WFLY-1339
>                 URL: https://issues.jboss.org/browse/WFLY-1339
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Domain is missing modcluster operations except for list-proxies:
> {code}
> [domain at localhost:9999 subsystem=modcluster] :
> list-proxies                read-children-resources     read-operation-names        read-resource               reset                       
> read-attribute              read-children-types         read-proxies-configuration  read-resource-description   undefine-attribute          
> read-children-names         read-operation-description  read-proxies-info           refresh                     write-attribute          
> {code}
> while in standalone we expose all of these operations:
> {code}
> [standalone at localhost:9999 subsystem=modcluster] :
> add                         enable                      read-children-names         read-operation-names        read-resource-description   reset                       whoami                      
> add-proxy                   enable-context              read-children-resources     read-proxies-configuration  refresh                     stop                        write-attribute             
> disable                     list-proxies                read-children-types         read-proxies-info           remove                      stop-context                
> disable-context             read-attribute              read-operation-description  read-resource               remove-proxy                undefine-attribute          
> {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 issues at jboss.org  Thu Jan 16 10:26:34 2014
From: issues at jboss.org (Ondrej Zizka (JIRA))
Date: Thu, 16 Jan 2014 10:26:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2427) Launcher API
In-Reply-To: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509240.1383251005000.47720.1389885994380@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936358#comment-12936358 ] 

Ondrej Zizka commented on WFLY-2427:
------------------------------------

We just had a discussion with David and Brian on EAP dev F2F, and we agreed that:

* The best would be to have this "Launcher API" library right in WildFly.
* It should use ProcessBuilder which would call standalone.sh/bat. Not the classes directly.
* It should implement some set of interfaces which would be very stable - no changes even between major versions (until the server paradigm changes, perhaps)
* The API should be extensible for 2 reasons:
   * Future additional parameters
   * Layered products

                
> Launcher API
> ------------
>
>                 Key: WFLY-2427
>                 URL: https://issues.jboss.org/browse/WFLY-2427
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. 
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. 
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -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 "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.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 issues at jboss.org  Thu Jan 16 10:28:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 10:28:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-353) Support for AS-specific
	mod_cluster metrics
In-Reply-To: <JIRA.12486203.1362418050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486203.1362418050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486203.1362418050000.47725.1389886113289@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-353:
--------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Support for AS-specific mod_cluster metrics
> -------------------------------------------
>
>                 Key: WFLY-353
>                 URL: https://issues.jboss.org/browse/WFLY-353
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR1
>
>
> If we want to create AS-specific load metrics that reference other AS services we need a way for the mod_cluster subsystem to configure these since currently load metrics are statically defined and are not configurable. E.g. connection-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 issues at jboss.org  Thu Jan 16 10:40:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 10:40:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-861) modcluster doesn't expose the
 jvmRoute information via cli. Can't execute *-context operations without it
 properly.
In-Reply-To: <JIRA.12466909.1337611081000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466909.1337611081000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466909.1337611081000.47745.1389886832961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-861:
--------------------------------

    Component/s: Web (Undertow)
                     (was: CLI)

    
> modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-861
>                 URL: https://issues.jboss.org/browse/WFLY-861
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: EAP6
>            Reporter: Simeon Pinder
>            Assignee: Radoslav Husar
>            Priority: Critical
>              Labels: rhq
>             Fix For: 8.0.0.Final
>
>
> The modcluster subsystem needs to expose the 'jvmRoute' identifier via cli for the modcluster subsystem at the configuration level(at subsystem=modcluster/mod-cluster-config=configuration level).  Without this information it is ambiguous how and which contexts will be affected when you execute the following operations:
> disable, disable-context, enable, enable-context, stop, stop-context.
> The other configuration attributes/operations target cluster-wide configuration, but the previous list of operations can only be executed at the cluster member/node level. In other words, a modcluster group could have 30 members/nodes but the above CLI operations will only affect the virtual-hosts and contexts for one of those nodes as uniquely identified by the jvmRoute.  There is currently no consistent way to determine what a valid cluster identifier should be.
> The jvmRoute can be explicitly set via the 'jboss.mod_cluster.jvmRoute' property or is automatically generated. Either way the correct jvmRoute or modcluster node identifier information needs to be correctly exposed as read-only information for the modcluster subsystem.
> This post (https://community.jboss.org/message/632900), mentions an 'instance-id' on the web subsytem but it is also 'undefined' even for systems where the jvmRoute has been explicitly set or autogenerated.  
> As the identifier is used by modcluster the identifier should be exposed consistently.
> Additionally there is no way to read whether a specific context is enabled/disabled. That issue probably needs it's another JIRA though.
>        

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:42:32 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 10:42:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-861) modcluster doesn't expose the
 jvmRoute information via cli. Can't execute *-context operations without it
 properly.
In-Reply-To: <JIRA.12466909.1337611081000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466909.1337611081000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466909.1337611081000.47749.1389886952867@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936362#comment-12936362 ] 

Radoslav Husar commented on WFLY-861:
-------------------------------------

Still relevant in WildFly. Undertow does not expose a way to get this:

{noformat}
[standalone at localhost:9990 /] /subsystem=undertow:read-resource(include-runtime=true,recursive=true)
{
    "outcome" => "success",
    "result" => {
        "default-server" => "default-server",
        "default-servlet-container" => "default",
        "default-virtual-host" => "default-host",
        "instance-id" => undefined,
...
{noformat}
                
> modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-861
>                 URL: https://issues.jboss.org/browse/WFLY-861
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>         Environment: EAP6
>            Reporter: Simeon Pinder
>            Assignee: Radoslav Husar
>            Priority: Critical
>              Labels: rhq
>             Fix For: 8.0.0.Final
>
>
> The modcluster subsystem needs to expose the 'jvmRoute' identifier via cli for the modcluster subsystem at the configuration level(at subsystem=modcluster/mod-cluster-config=configuration level).  Without this information it is ambiguous how and which contexts will be affected when you execute the following operations:
> disable, disable-context, enable, enable-context, stop, stop-context.
> The other configuration attributes/operations target cluster-wide configuration, but the previous list of operations can only be executed at the cluster member/node level. In other words, a modcluster group could have 30 members/nodes but the above CLI operations will only affect the virtual-hosts and contexts for one of those nodes as uniquely identified by the jvmRoute.  There is currently no consistent way to determine what a valid cluster identifier should be.
> The jvmRoute can be explicitly set via the 'jboss.mod_cluster.jvmRoute' property or is automatically generated. Either way the correct jvmRoute or modcluster node identifier information needs to be correctly exposed as read-only information for the modcluster subsystem.
> This post (https://community.jboss.org/message/632900), mentions an 'instance-id' on the web subsytem but it is also 'undefined' even for systems where the jvmRoute has been explicitly set or autogenerated.  
> As the identifier is used by modcluster the identifier should be exposed consistently.
> Additionally there is no way to read whether a specific context is enabled/disabled. That issue probably needs it's another JIRA though.
>        

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:44:32 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 16 Jan 2014 10:44:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot
 find custom ldap socket factory
In-Reply-To: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529141.1389397970000.47757.1389887072853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Derek Horton updated SECURITY-784:
----------------------------------

    Attachment: SECURITY-784.patch

    
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
>                 Key: SECURITY-784
>                 URL: https://issues.jboss.org/browse/SECURITY-784
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the  "java.naming.ldap.factory.socket" property in as an
> module-option:
>   <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
>      at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
>      at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
>      at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
>      at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk.  Unfortunately, that did not work.  I also added the socket
> factory jar to the jre/lib/ext directory.  That didn't work either.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:44:33 2014
From: issues at jboss.org (Derek Horton (JIRA))
Date: Thu, 16 Jan 2014 10:44:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot
 find custom ldap socket factory
In-Reply-To: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529141.1389397970000.47759.1389887073002@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936363#comment-12936363 ] 

Derek Horton commented on SECURITY-784:
---------------------------------------

Attached a first attempt at a fix.
                
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
>                 Key: SECURITY-784
>                 URL: https://issues.jboss.org/browse/SECURITY-784
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the  "java.naming.ldap.factory.socket" property in as an
> module-option:
>   <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
>      at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
>      at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
>      at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
>      at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk.  Unfortunately, that did not work.  I also added the socket
> factory jar to the jre/lib/ext directory.  That didn't work either.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 10:48:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 10:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-457) Replace mod_cluster proxy-list
 attribute with list of outbound socket bindings
In-Reply-To: <JIRA.12489843.1366309174000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489843.1366309174000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489843.1366309174000.47772.1389887313419@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-457:
--------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Replace mod_cluster proxy-list attribute with list of outbound socket bindings
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-457
>                 URL: https://issues.jboss.org/browse/WFLY-457
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR1
>
>
> Currently, the mod_cluster subsystem defines proxies using a comma separated string of address:port.  This attribute needs to be deprecated in favor of an attribute, call it "proxies" that defines an xs:list of outbound socket binding 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 issues at jboss.org  Thu Jan 16 10:48:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 10:48:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-358) Enable checkstyle for
 clustering integration testsuite
In-Reply-To: <JIRA.12485917.1362049129000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485917.1362049129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485917.1362049129000.47775.1389887313570@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-358:
--------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Enable checkstyle for clustering integration testsuite
> ------------------------------------------------------
>
>                 Key: WFLY-358
>                 URL: https://issues.jboss.org/browse/WFLY-358
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 9.0.0.CR1
>
>
> Ideally this will make live easier by less rebasing due to formatting differences and easier PR reviews. Lets see how it goes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 11:06:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 11:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1970) Make mod_cluster status
 interval configurable
In-Reply-To: <JIRA.12499638.1377789630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499638.1377789630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499638.1377789630000.47814.1389888393356@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-1970:
---------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Make mod_cluster status interval configurable
> ---------------------------------------------
>
>                 Key: WFLY-1970
>                 URL: https://issues.jboss.org/browse/WFLY-1970
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR1
>
>
> There is a TODO in UndertowEventHandlerAdapter.start(StartContext)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 11:06:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 16 Jan 2014 11:06:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1970) Make mod_cluster status
 interval configurable
In-Reply-To: <JIRA.12499638.1377789630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499638.1377789630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499638.1377789630000.47818.1389888393534@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936371#comment-12936371 ] 

Radoslav Husar commented on WFLY-1970:
--------------------------------------

Lets do this with a schema refresh for WF 9.

Regarding  catalina: no longer applies to wildfly since jboss web was ripped off. Now we have our own thread.
                
> Make mod_cluster status interval configurable
> ---------------------------------------------
>
>                 Key: WFLY-1970
>                 URL: https://issues.jboss.org/browse/WFLY-1970
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR1
>
>
> There is a TODO in UndertowEventHandlerAdapter.start(StartContext)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 11:12:32 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Thu, 16 Jan 2014 11:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2768) Redundant code hosted in
 arquillian directory
In-Reply-To: <JIRA.12529617.1389888691641@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529617.1389888691641@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529617.1389888691641.47830.1389888752709@jira02.app.mwc.hst.phx2.redhat.com>

Karel Piwko created WFLY-2768:
---------------------------------

             Summary: Redundant code hosted in arquillian directory
                 Key: WFLY-2768
                 URL: https://issues.jboss.org/browse/WFLY-2768
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Karel Piwko
            Assignee: Karel Piwko


There are two Maven modules that are not part of the codebase since mid 2011. It would be better to remove them.

These modules are:

* arquillian/protocol-servlet
* arquillian/processor-jsfunit

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 12:34:32 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Thu, 16 Jan 2014 12:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-401) OSGI Singleton option should
	not be used
In-Reply-To: <JIRA.12529454.1389770559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529454.1389770559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529454.1389770559000.48036.1389893672759@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard resolved DROOLS-401.
--------------------------------------

    Resolution: Done


Fixed with the following commits :

commit 83afcb4d9a626de03d9f1e3f5364001d0de49cc6
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 21:33:28 2014 +0100
 
    Remove singleton=true option as it blocks to update bundle on karaf
 
 jbpm-flow/pom.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
commit 5d58dc046a820882d8507c461da8244f90498089
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 21:31:06 2014 +0100
 
    Remove singleton=true option as it blocks to update bundle on karaf
 
 jbpm-flow-builder/pom.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
                
> OSGI Singleton option should not be used
> ----------------------------------------
>
>                 Key: DROOLS-401
>                 URL: https://issues.jboss.org/browse/DROOLS-401
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>
> OSGI Singleton Option should be used as we get this error when we update or restart  a bundle on Karaf/JBoss Fuse
> {code}
> Error executing command: Could not start bundle mvn:org.jbpm/jbpm-flow-builder/6.0.1.Final in feature(s) jbpm-6.0.1.Final: Unresolved constraint in bundle org.jbpm.flow.builder [388]: Singleton conflict.
> {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 issues at jboss.org  Thu Jan 16 12:36:33 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Thu, 16 Jan 2014 12:36:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-398) Drools & jbpms cannot be
 deployed on JBoss Fuse 6.0 / Karaf 2.3
In-Reply-To: <JIRA.12529450.1389770106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529450.1389770106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529450.1389770106000.48043.1389893793090@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard resolved DROOLS-398.
--------------------------------------

    Resolution: Done


Fixed with the following commits (and tested) :

===============================================================================
Repository: droolsjbpm-integration
===============================================================================
commit 83701b63bc13e37023fe8321cd81d0bb49d77f57
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 22:02:06 2014 +0100
 
    Fix version number, test camel drools decision table example with blueprint on karaf
 
 .../blueprint-camel-drools-decision-table-example/ReadMe.md             | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
commit 19f360dd05cc8797864f478162756e49f2c9a0be
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 21:54:14 2014 +0100
 
    Change version number of the features file
 
 .../spring-camel-drools-decision-table-example/ReadMe.md                | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
commit b908ac9fb1e2863e815dd9d1c41569867b12e976
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 21:44:45 2014 +0100
 
    Fix issues to deploy project on karaf - tested with jbpm-example
 
 .../filtered-resources/repository/features.xml     | 322 +++++++++++----------
 1 file changed, 170 insertions(+), 152 deletions(-)
 
commit aa177bb8f8a4cc6e819dff4526912c1efb03dda6
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 21:44:08 2014 +0100
 
    Change features required to deploy project on karaf and test jbpm-example
 
 .../droolsjbpm-osgi-examples/spring-jbpm-osgi-example/ReadMe.txt    | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
 
commit b963255dedb9f50428b0409cedef26c9eae9c7ea
Author: Charles Moulliard <ch007m at gmail.com>
Date:   Wed Jan 15 21:35:29 2014 +0100
 
    Change features required to deploy project on karaf and test jbpm-example
 
 .../droolsjbpm-osgi-examples/spring-jbpm-osgi-example/ReadMe.txt    | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
                
> Drools & jbpms cannot be deployed on JBoss Fuse 6.0 / Karaf 2.3
> ---------------------------------------------------------------
>
>                 Key: DROOLS-398
>                 URL: https://issues.jboss.org/browse/DROOLS-398
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>
> Due to refactoring of project kie-commons (merged with uberfire) and not longer required by jBPMN (to be verified), Drools and jbpmn 6.0.1.Final cannot be deployed anymore on JBoss Fuse / Karaf using the following features deployment command :
> {code}
> features:addurl mvn:org.drools/drools-karaf-features/6.0.1.Final/xml/features
> karaf at root> features:install kie-spring
> Error executing command: URL [mvn:org.kie.commons/kie-commons-cdi/6.0.1.Final] could not be resolved.
> {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 issues at jboss.org  Thu Jan 16 12:46:32 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 16 Jan 2014 12:46:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot
 find custom ldap socket factory
In-Reply-To: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529141.1389397970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529141.1389397970000.48046.1389894392868@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936423#comment-12936423 ] 

Stefan Guilhen commented on SECURITY-784:
-----------------------------------------

Derek, the patch looks ok to me. I think I would throw an exception if we can't acquire the module classloader.. in these cases letting it fall through and use the current classloader will probably result in an exception later on anyway.
                
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
>                 Key: SECURITY-784
>                 URL: https://issues.jboss.org/browse/SECURITY-784
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>         Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the  "java.naming.ldap.factory.socket" property in as an
> module-option:
>   <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
>      at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
>      at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
>      at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
>      at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
>      at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
>      at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk.  Unfortunately, that did not work.  I also added the socket
> factory jar to the jre/lib/ext directory.  That didn't work either.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 12:50:32 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Thu, 16 Jan 2014 12:50:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-400) jbpmn-audit-task should be
 OSGIFied (add OSGI MetaData)
In-Reply-To: <JIRA.12529452.1389770456000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529452.1389770456000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529452.1389770456000.48051.1389894632689@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard resolved DROOLS-400.
--------------------------------------

    Resolution: Done


Module already OSGIFied
                
> jbpmn-audit-task should be OSGIFied (add OSGI MetaData)
> -------------------------------------------------------
>
>                 Key: DROOLS-400
>                 URL: https://issues.jboss.org/browse/DROOLS-400
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>
> Jar is not a bundle, no Bundle-SymbolicName mvn:org.jbpm/jbpm-human-task-audit/6.0.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 issues at jboss.org  Thu Jan 16 13:46:33 2014
From: issues at jboss.org (Sachin Dole (JIRA))
Date: Thu, 16 Jan 2014 13:46:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-217) javassist does not work
 with java8 and lambda
In-Reply-To: <JIRA.12529629.1389897888436@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529629.1389897888436@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529629.1389897888436.48131.1389897993621@jira02.app.mwc.hst.phx2.redhat.com>

Sachin Dole created JASSIST-217:
-----------------------------------

             Summary: javassist does not work with java8 and lambda
                 Key: JASSIST-217
                 URL: https://issues.jboss.org/browse/JASSIST-217
             Project: Javassist
          Issue Type: Feature Request
    Affects Versions: 3.18.1-GA
         Environment: weld+tomcat
            Reporter: Sachin Dole
            Assignee: Shigeru Chiba
            Priority: Blocker


I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.

I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 

Is there a plan to fix support for java8?

If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 15:40:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Jan 2014 15:40:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-762) Bug in
 JBossJSSESecurityDomain.java - attempting to use wrong provider
In-Reply-To: <JIRA.12508715.1382627586000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508715.1382627586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508715.1382627586000.48264.1389904832905@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-762:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023084

    
> Bug in JBossJSSESecurityDomain.java - attempting to use wrong provider
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-762
>                 URL: https://issues.jboss.org/browse/SECURITY-762
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Anil Saldhana
>
> There is a bug in JBossJSSESecurityDomain.java where it attempts to use the keystore/truststore provider to get instances of the trust manager.
> The code reads:
>          if (trustManagerFactoryProvider != null)
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustStoreProvider);
>          else
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm);
> I think it should read:
>          if (trustManagerFactoryProvider != null)
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustManagerFactoryProvider);
>          else
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 21:50:32 2014
From: issues at jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jan 2014 21:50:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-217) javassist does not work
 with java8 and lambda
In-Reply-To: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529629.1389897888000.48670.1389927032907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936511#comment-12936511 ] 

Shigeru Chiba commented on JASSIST-217:
---------------------------------------

Yes, a project reproducing the fails in java 8 is appreciated.
The version numbers of all related products are also necessary.

                
> javassist does not work with java8 and lambda
> ---------------------------------------------
>
>                 Key: JASSIST-217
>                 URL: https://issues.jboss.org/browse/JASSIST-217
>             Project: Javassist
>          Issue Type: Feature Request
>    Affects Versions: 3.18.1-GA
>         Environment: weld+tomcat
>            Reporter: Sachin Dole
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>              Labels: java8, lambda
>
> I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.
> I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 
> Is there a plan to fix support for java8?
> If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 23:16:33 2014
From: issues at jboss.org (swapnesh sharma (JIRA))
Date: Thu, 16 Jan 2014 23:16:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2769) cli - command to add/remove
 AS modules from non-default module root
In-Reply-To: <JIRA.12529658.1389932180361@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529658.1389932180361@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529658.1389932180361.48689.1389932193863@jira02.app.mwc.hst.phx2.redhat.com>

swapnesh sharma created WFLY-2769:
-------------------------------------

             Summary: cli - command to add/remove AS modules from non-default module root
                 Key: WFLY-2769
                 URL: https://issues.jboss.org/browse/WFLY-2769
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CLI
            Reporter: swapnesh sharma
            Assignee: Alexey Loubyansky


cli - 'module add' always adds the module in %JOBSS_MODULE%/modules directory.
It will be nice to allow add to other default module directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 23:34:32 2014
From: issues at jboss.org (swapnesh sharma (JIRA))
Date: Thu, 16 Jan 2014 23:34:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2769) cli - command to add/remove
 AS modules from non-default module root
In-Reply-To: <JIRA.12529658.1389932180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529658.1389932180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529658.1389932180000.48696.1389933272918@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

swapnesh sharma updated WFLY-2769:
----------------------------------

    Description: 
cli - 'module add' always adds the module in %JOBSS_HOME%/modules directory.
It will be nice to allow add to other default module directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.

  was:
cli - 'module add' always adds the module in %JOBSS_MODULE%/modules directory.
It will be nice to allow add to other default module directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.


    
> cli - command to add/remove AS modules from non-default module root
> -------------------------------------------------------------------
>
>                 Key: WFLY-2769
>                 URL: https://issues.jboss.org/browse/WFLY-2769
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: swapnesh sharma
>            Assignee: Alexey Loubyansky
>
> cli - 'module add' always adds the module in %JOBSS_HOME%/modules directory.
> It will be nice to allow add to other default module directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 16 23:36:32 2014
From: issues at jboss.org (swapnesh sharma (JIRA))
Date: Thu, 16 Jan 2014 23:36:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2769) cli - command to add/remove
 AS modules from non-default module root
In-Reply-To: <JIRA.12529658.1389932180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529658.1389932180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529658.1389932180000.48699.1389933392743@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

swapnesh sharma updated WFLY-2769:
----------------------------------

    Description: 
cli - 'module add/remove' always adds/removes new module in %JOBSS_HOME%/modules directory.
It will be nice to allow add/remove from other default module root directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.

  was:
cli - 'module add' always adds the module in %JOBSS_HOME%/modules directory.
It will be nice to allow add to other default module directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.


    
> cli - command to add/remove AS modules from non-default module root
> -------------------------------------------------------------------
>
>                 Key: WFLY-2769
>                 URL: https://issues.jboss.org/browse/WFLY-2769
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: swapnesh sharma
>            Assignee: Alexey Loubyansky
>
> cli - 'module add/remove' always adds/removes new module in %JOBSS_HOME%/modules directory.
> It will be nice to allow add/remove from other default module root directory. Currently only search is allowed for this using JBOSS_MODULEPATH or -mp.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 01:00:45 2014
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Fri, 17 Jan 2014 01:00:45 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2766) .jar's on "current runtime
	classpath"
In-Reply-To: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529603.1389881603000.48723.1389938445775@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936522#comment-12936522 ] 

Rob Stryker commented on WFLY-2766:
-----------------------------------

One of the issues I see here is that users often start off with minimal dependencies and then add more. In the past we've made most APIs available on the classpath. Take this example:  A user makes a web project, and for a few days just makes servlets and business logic. Then they decide they need mail added.   How would they go about adding this dependency?

If the jars aren't already on the classpath, they won't be able to autocomplete their mail packages as they try to type them in. How would the user be expected to indicate they need mail so that typing in mail works for auto-complete? 
                
> .jar's on "current runtime classpath"
> -------------------------------------
>
>                 Key: WFLY-2766
>                 URL: https://issues.jboss.org/browse/WFLY-2766
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ondrej Zizka
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra)  have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 02:07:33 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 17 Jan 2014 02:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.48756.1389942453476@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936527#comment-12936527 ] 

Jozef Hartinger commented on WFLY-2751:
---------------------------------------

I suggest that you do not map the CDI Conversation Filter which will cause CDI conversations to be activated lazily. This is not in CR1. You would have to use the current SNAPSHOT or wait for FINAL.
                
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	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.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 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 issues at jboss.org  Fri Jan 17 02:59:32 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 17 Jan 2014 02:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-402) Programmatic rule update
	fails
In-Reply-To: <JIRA.12529486.1389790486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529486.1389790486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529486.1389790486000.48794.1389945572843@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-402:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Programmatic rule update fails
> ------------------------------
>
>                 Key: DROOLS-402
>                 URL: https://issues.jboss.org/browse/DROOLS-402
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Windows 7
>            Reporter: Markus Tippmann
>            Assignee: Mario Fusco
>         Attachments: drools.test.zip
>
>
> Programmatic construction of a kmodule and updating its rules fails with different problems. 
> I attach a small Maven project which runs 3 tests (one succeeds just for demonstration). I hope I'm doing correctly here on kmodule construction.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 03:57:33 2014
From: issues at jboss.org (Paul Robinson (JIRA))
Date: Fri, 17 Jan 2014 03:57:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1929) TransactionalInterceptorBase
 doesn't implement Serializable
In-Reply-To: <JIRA.12499214.1377186519000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499214.1377186519000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499214.1377186519000.48848.1389949053116@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Robinson resolved WFLY-1929.
---------------------------------

    Resolution: Done

    
> TransactionalInterceptorBase doesn't implement Serializable
> -----------------------------------------------------------
>
>                 Key: WFLY-1929
>                 URL: https://issues.jboss.org/browse/WFLY-1929
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Paul Robinson
>
> I just downloaded the latest WildFly snapshot which contains an upgrade of IronJacamar. The annotation @Transactional works fine for @RequestScoped requests (see WFLY-1496).
> However, if I'm using @SessionScoped for CDI beans in a JSF-based web application, then I get the stacktrace below. The solution is pretty simple:
> The interceptor class TransactionalInterceptorBase in Narayana's package com.arjuna.ats.jta.cdi.transactional has to implement the interface java.io.Serializable.
> The stacktrace:
> {code}
> 17:25:52,861 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop2.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop2.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001527 Managed bean declaring a passivating scope has a non-serializable interceptor.  Bean:  Managed Bean [class de.shop.auth.web.AuthModel] with qualifiers [@Default @Any @Named]  Interceptor: org.jboss.weld.interceptor.reader.DefaultInterceptorMetadata at 63abbf61
> 	at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:214)
> 	at org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:115)
> 	at org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:122)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:129)
> 	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:120)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	... 3 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 04:07:33 2014
From: issues at jboss.org (Andre Pankraz (JIRA))
Date: Fri, 17 Jan 2014 04:07:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2751) h:inputFile and max-file-size
In-Reply-To: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529408.1389714544000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529408.1389714544000.48865.1389949653344@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936539#comment-12936539 ] 

Andre Pankraz commented on WFLY-2751:
-------------------------------------

Hi, I have no problem with waiting for a Final or building from Snapshot etc. I know you can nothing do about CR1 state, it's released after all. Just hope the problems it will be resolved, thats all. I can find some workaround this long.
                
> h:inputFile and max-file-size
> -----------------------------
>
>                 Key: WFLY-2751
>                 URL: https://issues.jboss.org/browse/WFLY-2751
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Open JDK 7, Cent OS
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>
> If I use h:inputFile (JSF) together with something like e.g.:
> 	<servlet>
> 		<servlet-name>Faces Servlet</servlet-name>
> 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> 		<load-on-startup>1</load-on-startup>
> 		<multipart-config>
> 			<location>/tmp</location>
> 			<max-file-size>1000</max-file-size>
> 			<max-request-size>2000</max-request-size>
> 			<file-size-threshold>500</file-size-threshold>
> 		</multipart-config>
> 	</servlet>
> and I upload a file which exceeds the max-file-size, I get an exception in the attached style (below).
> I cannot really react to this exception in JSF (global exception handler will not notice this because exception not in context of faces servlet) or in web-xml exception-handlers (to generic RuntimeException, not even an IllegalArgumentException like in spec?!).
> I would expect that this heavily restricts the usability if this new JSF component? I could switch off the restrictions and write a custom validator to check the part-size, but this is not very secure - the to large file is then already written to the given folder?!
> Exception is:
> 16:08:06,837 ERROR [io.undertow.request] (default task-14) Servlet request failed HttpServerExchange{ POST /...Upload.xhtml}: java.lang.RuntimeException: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:705) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:577) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at org.jboss.weld.servlet.ConversationContextActivator.getConversationId(ConversationContextActivator.java:124) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:91) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationContextActivator.startConversationContext(ConversationContextActivator.java:79) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at org.jboss.weld.servlet.ConversationFilter.doFilter(ConversationFilter.java:68) [weld-core-impl-2.1.0.Final.jar:2013-10-11 10:25]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:29) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at de.init.xrepository.util.PageExpiryFilter.doFilter(PageExpiryFilter.java:166) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	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.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.IOException: UT000054: The maximum size 1000 for an individual file in a multipart request was exceeded
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.data(MultiPartParserDefinition.java:246) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$IdentityEncoding.handle(MultipartParser.java:328) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.entity(MultipartParser.java:306) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.util.MultipartParser$ParseState.parse(MultipartParser.java:111) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:196) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.parseFormData(HttpServletRequestImpl.java:703) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	... 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 issues at jboss.org  Fri Jan 17 04:57:32 2014
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Fri, 17 Jan 2014 04:57:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2610) Add the ability to take an
 external based password to the Vault tool
In-Reply-To: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527043.1386238103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527043.1386238103000.48982.1389952652905@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-2610:
--------------------------------

    Fix Version/s: 8.0.0.Final

    
> Add the ability to take an external based password to the Vault tool
> --------------------------------------------------------------------
>
>                 Key: WFLY-2610
>                 URL: https://issues.jboss.org/browse/WFLY-2610
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Scripts, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> At the moment the Vault tool only supports plain text password as a parameter. With SECURITY-770 committed in it is also possible to configure the Vault to take an external password. Thus the Vault tool needs to support it too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 05:49:33 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 17 Jan 2014 05:49:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2770) CDI Decorator should be
 enable on Websocket enpoint
In-Reply-To: <JIRA.12529678.1389955721767@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529678.1389955721767@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529678.1389955721767.49075.1389955773398@jira02.app.mwc.hst.phx2.redhat.com>

Antoine Sabot-Durand created WFLY-2770:
------------------------------------------

             Summary: CDI Decorator should be  enable on Websocket enpoint
                 Key: WFLY-2770
                 URL: https://issues.jboss.org/browse/WFLY-2770
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Antoine Sabot-Durand
            Assignee: Stuart Douglas


Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature 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 issues at jboss.org  Fri Jan 17 05:51:32 2014
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 17 Jan 2014 05:51:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2770) CDI Decorator should be
 enable on Websocket enpoint
In-Reply-To: <JIRA.12529678.1389955721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529678.1389955721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529678.1389955721000.49077.1389955892696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated WFLY-2770:
---------------------------------------

    Attachment: websocket-decorator.zip


An example application that decorates a websocket endpoint. This example app work under Glassfish and doesn't under Wildfly
                
> CDI Decorator should be  enable on Websocket enpoint
> ----------------------------------------------------
>
>                 Key: WFLY-2770
>                 URL: https://issues.jboss.org/browse/WFLY-2770
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Antoine Sabot-Durand
>            Assignee: Stuart Douglas
>         Attachments: websocket-decorator.zip
>
>
> Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature 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 issues at jboss.org  Fri Jan 17 06:13:33 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jan 2014 06:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1771) Replace Exposed{Input,
 Output}Stream with ByteArray{Input, Output}Stream
In-Reply-To: <JIRA.12529680.1389957103870@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529680.1389957103870@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529680.1389957103870.49085.1389957213841@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1771:
------------------------------

             Summary: Replace Exposed{Input,Output}Stream with ByteArray{Input,Output}Stream
                 Key: JGRP-1771
                 URL: https://issues.jboss.org/browse/JGRP-1771
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
The problem is that DataInputStream creates an 80 byte buffer for every creation.
Same thing for sending a message or message list.

SOLUTION:
* Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
*** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
* Similar solution for sending of messages / message lists

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 06:33:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jan 2014 06:33:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1772) Optimize marshalling of
	strings
In-Reply-To: <JIRA.12529684.1389958324341@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529684.1389958324341@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529684.1389958324341.49123.1389958412919@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1772:
------------------------------

             Summary: Optimize marshalling of strings
                 Key: JGRP-1772
                 URL: https://issues.jboss.org/browse/JGRP-1772
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


Currently, we use DataOutput.writeUTF() for all sorts of strings. This is implemented inefficiently and potentially uses more than 1 byte per char.
Add another method writeString() which converts double byte chars to single byte chars so that only ASCII is supported. This can be used by a lot of internal code which never uses chars above 128.
For external code, such as {{JChannel.connect(String cluster_name)}}, we need to see whether this is ok. Since cluster names are mainly used to differentiate clusters, perhaps it is ok to mangle the names to chars below 128, although this would change cluster names which use multi-byte chars.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 06:33:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 17 Jan 2014 06:33:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-342) Reenable
 ClusteredSingleSignOnTestCase test to work with Undertow
In-Reply-To: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471898.1344331018000.49126.1389958413102@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-342:
-----------------------------------

    Assignee: Paul Ferraro

    
> Reenable ClusteredSingleSignOnTestCase test to work with Undertow 
> ------------------------------------------------------------------
>
>                 Key: WFLY-342
>                 URL: https://issues.jboss.org/browse/WFLY-342
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Kabir Khan
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>         Attachments: ClusteredSingleSignOnTestCase1.html, ClusteredSingleSignOnTestCase2.html, ClusteredSingleSignOnTestCase3.html
>
>
> Test have been @Ignored until Undertow implements SSO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 06:35:32 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 17 Jan 2014 06:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2771) Add distributable single sign
 on support to undertow
In-Reply-To: <JIRA.12529685.1389958433463@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529685.1389958433463@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529685.1389958433463.49139.1389958532953@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2771:
----------------------------------

             Summary: Add distributable single sign on support to undertow
                 Key: WFLY-2771
                 URL: https://issues.jboss.org/browse/WFLY-2771
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 9.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 issues at jboss.org  Fri Jan 17 06:35:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 17 Jan 2014 06:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-381) Re-enable mod_cluster
 subsystem to work with Undertow
In-Reply-To: <JIRA.12488031.1364304059000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488031.1364304059000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488031.1364304059000.49146.1389958533305@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-381:
--------------------------------

    Summary: Re-enable mod_cluster subsystem to work with Undertow  (was: Re-enable Mod cluster)

    
> Re-enable mod_cluster subsystem to work with Undertow
> -----------------------------------------------------
>
>                 Key: WFLY-381
>                 URL: https://issues.jboss.org/browse/WFLY-381
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha3
>
>
> Fix mod cluster to work with 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 issues at jboss.org  Fri Jan 17 06:35:33 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 17 Jan 2014 06:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-381) Re-enable mod_cluster
 subsystem to work with Undertow
In-Reply-To: <JIRA.12488031.1364304059000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488031.1364304059000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488031.1364304059000.49150.1389958533546@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-381.
-------------------------------


    
> Re-enable mod_cluster subsystem to work with Undertow
> -----------------------------------------------------
>
>                 Key: WFLY-381
>                 URL: https://issues.jboss.org/browse/WFLY-381
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha3
>
>
> Fix mod cluster to work with 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 issues at jboss.org  Fri Jan 17 06:55:34 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 17 Jan 2014 06:55:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-283) EJB timers in cluster and
	failover support
In-Reply-To: <JIRA.12460393.1330513902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460393.1330513902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460393.1330513902000.49194.1389959734241@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned WFLY-283:
---------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)

    
> EJB timers in cluster and failover support
> ------------------------------------------
>
>                 Key: WFLY-283
>                 URL: https://issues.jboss.org/browse/WFLY-283
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, EJB
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> Support for clustered EJB timer service providing failover.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 06:59:32 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jan 2014 06:59:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1773)
 TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
In-Reply-To: <JIRA.12529686.1389959943116@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529686.1389959943116@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529686.1389959943116.49202.1389959972715@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1773:
------------------------------

             Summary: TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
                 Key: JGRP-1773
                 URL: https://issues.jboss.org/browse/JGRP-1773
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


When a single message is received, we pass it to the thread pool for parsing, passing a copy of the byte array to the MyHandler runnable.
The parsing then creates a new Message and calls readFrom(). This method reads the headers and then creates a payload buffer of the size read from the input stream, then copies {{size}} bytes from the input stream to the mesage's payload.
This is an unneeded copy; as we already have a copy of the byte array, we only need to *reference* the byte array from the message and set the offset and length, saving us one copy of the buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 07:09:32 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 17 Jan 2014 07:09:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2772) Leverage JGroups FORK to
 consolidate EE channels
In-Reply-To: <JIRA.12529687.1389960535808@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529687.1389960535808@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529687.1389960535808.49218.1389960572851@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2772:
----------------------------------

             Summary: Leverage JGroups FORK to consolidate EE channels
                 Key: WFLY-2772
                 URL: https://issues.jboss.org/browse/WFLY-2772
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 07:11:32 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:11:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670311@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670311@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670311.49221.1389960692974@jira02.app.mwc.hst.phx2.redhat.com>

Nandor Galambosi created DROOLS-404:
---------------------------------------

             Summary: NoClassDefFoundError happens when using "function"s in drl
                 Key: DROOLS-404
                 URL: https://issues.jboss.org/browse/DROOLS-404
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final, 6.0.1.Final
         Environment: The base environment is the same as DefaultKieSessionExample.
See attached maven project for details.

            Reporter: Nandor Galambosi
            Assignee: Mark Proctor


If I reuse a KieSession for multiple times, it seems to forget about a function defined in the DRL file.
DRL: 
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 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 issues at jboss.org  Fri Jan 17 07:13:33 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:13:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529023.1389287238000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238000.49226.1389960813339@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-396:
------------------------------------

    Attachment: noclassdeffound.zip

    
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-396
>                 URL: https://issues.jboss.org/browse/DROOLS-396
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: leonardo lizana
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: noclassdeffound.zip
>
>
> I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
> is there anything that i'm doing bad?
> * with drools 5.5 everything is working OK.
> Here is my pom.xml
> --------------------------
> <dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>knowledge-api</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-core</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-compiler</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-spring</artifactId>
> 			<version>5.5.0.Final</version>
> 		</dependency>
> here is the log error:
> ----------------------------
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> 	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
> 	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
> 	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
> 	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
> 	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
> 	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
> 	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
> 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
> 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
> Here is the contex-drools.xml
> -------------------------------------
> <beans xmlns="http://www.springframework.org/schema/beans"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:context="http://www.springframework.org/schema/context"
>     xmlns:drools="http://drools.org/schema/drools-spring"
>     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
>     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
>     http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
>     default-autowire="byName">
>      
>   <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
>   <drools:kbase id="kBaseEnergyUsage">
>     <drools:resources>
>       <drools:resource ref="rulesEnergyUsage"/>
>     </drools:resources>
>   </drools:kbase>
>   <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
>  </beans>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 07:15:34 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49230.1389960934381@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Description: 
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more

  was:
If I reuse a KieSession for multiple times, it seems to forget about a function defined in the DRL file.
DRL: 
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more


    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> Exception:
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:21:32 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:21:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49239.1389961292711@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Description: 
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
[code]
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
[code]
Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more

  was:
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more


    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> [code]
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> [code]
> Exception:
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:23:32 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:23:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49241.1389961412736@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Description: 
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
<code>
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
<code>

Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more

  was:
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
[code]
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
[code]
Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more


    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> <code>
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> <code>
> Exception:
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:25:33 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49245.1389961533432@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Description: 
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
{noformat}
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
{noformat}

Exception:
{noformat}
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more
{noformat}

  was:
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
<code>
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
<code>

Exception:
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more


    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Exception:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:25:33 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:25:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49247.1389961533758@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Description: 
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
{noformat}
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
{noformat}

Java code:
{noformat}
package org.drools.example.api.defaultkiesession;

import org.kie.api.KieServices;
import org.kie.api.runtime.KieContainer;
import org.kie.api.runtime.KieSession;

public class DefaultKieSessionExample
{
    static int counter = 0;
    public void failCase1()
    {
        KieServices ks = KieServices.Factory.get();
        KieContainer kContainer = ks.getKieClasspathContainer();

        KieSession kSession = kContainer.newKieSession();
        for( counter = 0; counter < 10000; ++counter) {
            kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
            kSession.fireAllRules();
            if (kSession.getFactCount() != 0) {
                System.err.println("error");
            }
        }
    }

    public static void main(String[] args)
    {
        try {
            DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
            defaultKieSessionExample.failCase1();
        } catch (NoClassDefFoundError error) {
            System.err.println("Failed after "+counter+" testcases");
            error.printStackTrace();
        }
    }

}
{noformat}

Exception:
{noformat}
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more
{noformat}

  was:
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
{noformat}
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
{noformat}

Exception:
{noformat}
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more
{noformat}


    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Exception:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:29:32 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:29:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49251.1389961772840@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Description: 
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
{noformat}
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
{noformat}

Java code:
{noformat}
package org.drools.example.api.defaultkiesession;

import org.kie.api.KieServices;
import org.kie.api.runtime.KieContainer;
import org.kie.api.runtime.KieSession;

public class DefaultKieSessionExample
{
    static int counter = 0;
    public void failCase1()
    {
        KieServices ks = KieServices.Factory.get();
        KieContainer kContainer = ks.getKieClasspathContainer();

        KieSession kSession = kContainer.newKieSession();
        for( counter = 0; counter < 10000; ++counter) {
            kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
            kSession.fireAllRules();
            if (kSession.getFactCount() != 0) {
                System.err.println("error");
            }
        }
    }

    public static void main(String[] args)
    {
        try {
            DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
            defaultKieSessionExample.failCase1();
        } catch (NoClassDefFoundError error) {
            System.err.println("Failed after "+counter+" testcases");
            error.printStackTrace();
        }
    }

}
{noformat}

Runs fine for some iterations, and after a while an exception happens:
{noformat}
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more
{noformat}

  was:
If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
DRL: 
{noformat}
package org.drools.example.api.defaultkiesession.Hal1

import org.drools.example.api.defaultkiesession.Message

function boolean alwaysTrue() { 
	return true;
}

rule "rule 1" when
    m : Message( )
then
    retract(m);
end

rule "rule 2" when
    Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
then
    insert( new Message("HAL", "Dave. I read you." ) );
end
{noformat}

Java code:
{noformat}
package org.drools.example.api.defaultkiesession;

import org.kie.api.KieServices;
import org.kie.api.runtime.KieContainer;
import org.kie.api.runtime.KieSession;

public class DefaultKieSessionExample
{
    static int counter = 0;
    public void failCase1()
    {
        KieServices ks = KieServices.Factory.get();
        KieContainer kContainer = ks.getKieClasspathContainer();

        KieSession kSession = kContainer.newKieSession();
        for( counter = 0; counter < 10000; ++counter) {
            kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
            kSession.fireAllRules();
            if (kSession.getFactCount() != 0) {
                System.err.println("error");
            }
        }
    }

    public static void main(String[] args)
    {
        try {
            DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
            defaultKieSessionExample.failCase1();
        } catch (NoClassDefFoundError error) {
            System.err.println("Failed after "+counter+" testcases");
            error.printStackTrace();
        }
    }

}
{noformat}

Exception:
{noformat}
java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	... 15 more
{noformat}


    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:33:32 2014
From: issues at jboss.org (Nandor Galambosi (JIRA))
Date: Fri, 17 Jan 2014 07:33:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.49254.1389962012744@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandor Galambosi updated DROOLS-404:
------------------------------------

    Attachment: noclassdeffound.zip


Simple Maven project to reproduce the issue.
                
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>         Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 17 07:53:33 2014
From: issues at jboss.org (Jan Martiska (JIRA))
Date: Fri, 17 Jan 2014 07:53:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2773) ClientConfigurationImpl
 should not translate IP address to host name
In-Reply-To: <JIRA.12529691.1389963183093@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529691.1389963183093@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529691.1389963183093.49297.1389963213087@jira02.app.mwc.hst.phx2.redhat.com>

Jan Martiska created WFLY-2773:
----------------------------------

             Summary: ClientConfigurationImpl should not translate IP address to host name
                 Key: WFLY-2773
                 URL: https://issues.jboss.org/browse/WFLY-2773
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Jan Martiska
            Assignee: Jan Martiska


When creating a ModelControllerClient and passing in an IP address, ClientConfigurationImpl internally translates it to a host name, like here:
{noformat}
public static ModelControllerClientConfiguration create(final InetAddress address, final int port) {
        return new ClientConfigurationImpl(address.getHostName(), port, null, null, null, createDefaultExecutor(), true, null);
    }
{noformat}
Later on, when the client connects, it is translated via DNS back to an IP address. This is not only unnecessary, but in some situations, it is wrong.

Consider a Windows machine having two IP addresses ,A and B, on one network interface, where only A is pointed at by a DNS record. 
- Run AS testsuite and pass it the address B as the node0 property, AS will bind itself to this address.
- Now when a test creates a ModelControllerClient using IP address B, the address B will get translated to the host name, even though B is not in the DNS. The resolving works this way on a Windows machine.
- During the connection, the host name will get resolved by DNS to address A and the test will try to connect through address A. The connection will be refused, or worse, might connect to another instance on the same machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 09:00:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 17 Jan 2014 09:00:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-385) KModules get added twice
In-Reply-To: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528350.1387663007000.49432.1389967234273@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936611#comment-12936611 ] 

RH Bugzilla Integration commented on DROOLS-385:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1046095|https://bugzilla.redhat.com/show_bug.cgi?id=1046095] from MODIFIED to ON_QA
                
> KModules get added twice
> ------------------------
>
>                 Key: DROOLS-385
>                 URL: https://issues.jboss.org/browse/DROOLS-385
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mario Fusco
>
> The class loader is returning duplicate entries, as it incorrectly implements:
>     @Override
>     protected Enumeration<URL> findResources(String name) throws IOException {
>         return getParent().getResources(name);
>     }
> Deleting this method resolves the problem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 09:00:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 17 Jan 2014 09:00:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.49439.1389967234598@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936613#comment-12936613 ] 

RH Bugzilla Integration commented on DROOLS-373:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1039676|https://bugzilla.redhat.com/show_bug.cgi?id=1039676] from MODIFIED to ON_QA
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools6scratch-kiemavenclasspath.zip
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Fri Jan 17 09:52:33 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 17 Jan 2014 09:52:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2679) Jdbc cache store couldn't
 read databaseType property
In-Reply-To: <JIRA.12527992.1387184087000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527992.1387184087000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527992.1387184087000.49567.1389970353563@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes reopened WFLY-2679:
-------------------------------



I am still facing the exception using today's WildFly Final-SNAPSHOT. Yes I know, I meant property from configuration point of view. I think this needs fix in infinispan-cachestore-jdbc, where I can't still see the setter for this attribute in org/infinispan/persistence/jdbc/TableManipulation.java
                
> Jdbc cache store couldn't read databaseType property
> ----------------------------------------------------
>
>                 Key: WFLY-2679
>                 URL: https://issues.jboss.org/browse/WFLY-2679
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly 8.0.0.Beta2-SNAPSHOT (from 2013-12-16
>            Reporter: Tomas Remes
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Final
>
>
> If you want use some driver, which  type is not recognizable by Infinispan (e.g. jtds driver), then you are asked to specify your DB type via "databaseType" property in your cache store configuration. But when you specify it, you'll get following exception:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Couldn't find a setter named [setDatabaseType] which takes a single parameter, for parameter databaseType on class [class org.infinispan.persistence.jdbc.configuration.JdbcBinaryStoreConfigurationBuilder]
> 	at org.infinispan.configuration.parsing.XmlConfigHelper.setValues(XmlConfigHelper.java:450)
> 	at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:91)
> 	at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:9)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.processModelNode(CacheAdd.java:542)
> 	at org.jboss.as.clustering.infinispan.subsystem.ClusteredCacheAdd.processModelNode(ClusteredCacheAdd.java:69)
> 	at org.jboss.as.clustering.infinispan.subsystem.SharedStateCacheAdd.processModelNode(SharedStateCacheAdd.java:50)
> 	at org.jboss.as.clustering.infinispan.subsystem.DistributedCacheAdd.processModelNode(DistributedCacheAdd.java:90)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.installRuntimeServices(CacheAdd.java:205)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.performRuntime(CacheAdd.java:179)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:343) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {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 issues at jboss.org  Fri Jan 17 09:54:32 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 17 Jan 2014 09:54:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2679) Jdbc cache store couldn't
 read databaseType property
In-Reply-To: <JIRA.12527992.1387184087000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527992.1387184087000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527992.1387184087000.49575.1389970472970@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated WFLY-2679:
------------------------------

    Affects Version/s: 8.0.0.CR1
                           (was: 8.0.0.Beta1)
          Environment: WildFly 8.0.0.Final-SNAPSHOT from 2014-01-17  (was: WildFly 8.0.0.Beta2-SNAPSHOT (from 2013-12-16)

    
> Jdbc cache store couldn't read databaseType property
> ----------------------------------------------------
>
>                 Key: WFLY-2679
>                 URL: https://issues.jboss.org/browse/WFLY-2679
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.Final-SNAPSHOT from 2014-01-17
>            Reporter: Tomas Remes
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Final
>
>
> If you want use some driver, which  type is not recognizable by Infinispan (e.g. jtds driver), then you are asked to specify your DB type via "databaseType" property in your cache store configuration. But when you specify it, you'll get following exception:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Couldn't find a setter named [setDatabaseType] which takes a single parameter, for parameter databaseType on class [class org.infinispan.persistence.jdbc.configuration.JdbcBinaryStoreConfigurationBuilder]
> 	at org.infinispan.configuration.parsing.XmlConfigHelper.setValues(XmlConfigHelper.java:450)
> 	at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:91)
> 	at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:9)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.processModelNode(CacheAdd.java:542)
> 	at org.jboss.as.clustering.infinispan.subsystem.ClusteredCacheAdd.processModelNode(ClusteredCacheAdd.java:69)
> 	at org.jboss.as.clustering.infinispan.subsystem.SharedStateCacheAdd.processModelNode(SharedStateCacheAdd.java:50)
> 	at org.jboss.as.clustering.infinispan.subsystem.DistributedCacheAdd.processModelNode(DistributedCacheAdd.java:90)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.installRuntimeServices(CacheAdd.java:205)
> 	at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.performRuntime(CacheAdd.java:179)
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:343) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {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 issues at jboss.org  Fri Jan 17 10:34:33 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Fri, 17 Jan 2014 10:34:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1773)
 TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
In-Reply-To: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529686.1389959943000.49638.1389972873007@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936651#comment-12936651 ] 

Sanne Grinovero commented on JGRP-1773:
---------------------------------------

[~pruivo] was also interested in this, and asked why we can't be clever in UDP's org.jgroups.protocols.UDP.PacketReceiver.run() 

Wouldn't it be nice to allocate only the receive buffer size of the minimal size possible?

I'd say it should not use a size larger than the IPv4/6 required size at least, but maybe we can even look into the header to understand how long the buffer for the copy needs to be?
                
> TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
> --------------------------------------------------------------------------
>
>                 Key: JGRP-1773
>                 URL: https://issues.jboss.org/browse/JGRP-1773
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When a single message is received, we pass it to the thread pool for parsing, passing a copy of the byte array to the MyHandler runnable.
> The parsing then creates a new Message and calls readFrom(). This method reads the headers and then creates a payload buffer of the size read from the input stream, then copies {{size}} bytes from the input stream to the mesage's payload.
> This is an unneeded copy; as we already have a copy of the byte array, we only need to *reference* the byte array from the message and set the offset and length, saving us one copy of the buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 11:08:32 2014
From: issues at jboss.org (Sachin Dole (JIRA))
Date: Fri, 17 Jan 2014 11:08:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-217) javassist does not work
 with java8 and lambda
In-Reply-To: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529629.1389897888000.49719.1389974912979@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sachin Dole updated JASSIST-217:
--------------------------------

    Description: 
  I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.

I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 

Is there a plan to fix support for java8?

If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.

  was:
I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.

I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 

Is there a plan to fix support for java8?

If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.


    
> javassist does not work with java8 and lambda
> ---------------------------------------------
>
>                 Key: JASSIST-217
>                 URL: https://issues.jboss.org/browse/JASSIST-217
>             Project: Javassist
>          Issue Type: Feature Request
>    Affects Versions: 3.18.1-GA
>         Environment: weld+tomcat
>            Reporter: Sachin Dole
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>              Labels: java8, lambda
>
>   I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.
> I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 
> Is there a plan to fix support for java8?
> If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 11:08:33 2014
From: issues at jboss.org (Sachin Dole (JIRA))
Date: Fri, 17 Jan 2014 11:08:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-217) javassist does not work
 with java8 and lambda
In-Reply-To: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529629.1389897888000.49721.1389974913103@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936663#comment-12936663 ] 

Sachin Dole commented on JASSIST-217:
-------------------------------------

I am sorry, the bug is with ASM not with javassist. https://java.net/jira/browse/HK2-136 closing.
                
> javassist does not work with java8 and lambda
> ---------------------------------------------
>
>                 Key: JASSIST-217
>                 URL: https://issues.jboss.org/browse/JASSIST-217
>             Project: Javassist
>          Issue Type: Feature Request
>    Affects Versions: 3.18.1-GA
>         Environment: weld+tomcat
>            Reporter: Sachin Dole
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>              Labels: java8, lambda
>
>   I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.
> I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 
> Is there a plan to fix support for java8?
> If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 11:10:32 2014
From: issues at jboss.org (Sachin Dole (JIRA))
Date: Fri, 17 Jan 2014 11:10:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-217) javassist does not work
 with java8 and lambda
In-Reply-To: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529629.1389897888000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529629.1389897888000.49725.1389975032742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sachin Dole closed JASSIST-217.
-------------------------------

    Resolution: Cannot Reproduce Bug

    
> javassist does not work with java8 and lambda
> ---------------------------------------------
>
>                 Key: JASSIST-217
>                 URL: https://issues.jboss.org/browse/JASSIST-217
>             Project: Javassist
>          Issue Type: Feature Request
>    Affects Versions: 3.18.1-GA
>         Environment: weld+tomcat
>            Reporter: Sachin Dole
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>              Labels: java8, lambda
>
>   I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.
> I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code. 
> Is there a plan to fix support for java8?
> If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 13:08:32 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 17 Jan 2014 13:08:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2774) Non-distributed,
 stateful web applications cannot be load balanced using sticky
 sessions
In-Reply-To: <JIRA.12529716.1389982010382@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529716.1389982010382@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529716.1389982010382.49883.1389982112751@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2774:
----------------------------------

             Summary: Non-distributed, stateful web applications cannot be load balanced using sticky sessions
                 Key: WFLY-2774
                 URL: https://issues.jboss.org/browse/WFLY-2774
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Critical
             Fix For: 8.0.0.Final


In AS7, one could configure a load balancer with sticky sessions to support load balancing for non-distributed web applications.
While the distributed session manager supports parsing and formatting of the instance-id from/to the session id, the in-memory session manager does not.
The use case for this are stateful web applications that do not require high-availability of state (e.g. a stateless web-app that uses container managed authentication), but would also like to scale beyond the capacity of a single 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 issues at jboss.org  Fri Jan 17 13:12:32 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Fri, 17 Jan 2014 13:12:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-399) itest of Karaf are disabled
In-Reply-To: <JIRA.12529451.1389770282000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529451.1389770282000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529451.1389770282000.49888.1389982352748@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard resolved DROOLS-399.
--------------------------------------

    Resolution: Done


Tests work again. Fixed them 

[master 716fba9] Fix issues with itests of karaf
                
> itest of Karaf are disabled 
> ----------------------------
>
>                 Key: DROOLS-399
>                 URL: https://issues.jboss.org/browse/DROOLS-399
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            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 issues at jboss.org  Fri Jan 17 13:14:33 2014
From: issues at jboss.org (Cody Lerum (JIRA))
Date: Fri, 17 Jan 2014 13:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2488) Adding a datasource fails in
 a composite operation
In-Reply-To: <JIRA.12524806.1384188210000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524806.1384188210000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524806.1384188210000.49895.1389982473048@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936687#comment-12936687 ] 

Cody Lerum commented on WFLY-2488:
----------------------------------

For what it is worth I ran into the same issue with the wildfly-maven-plugin and removing the enableResource portion resolved it.

{code}
<resources>
   <resource>
     <enableResource>true</enableResource>
     <properties>
      ......
{code}
                
> Adding a datasource fails in a composite operation
> --------------------------------------------------
>
>                 Key: WFLY-2488
>                 URL: https://issues.jboss.org/browse/WFLY-2488
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Perkins
>            Assignee: Stefano Maestri
>         Attachments: wfly2488-sources.jar, wfly2488.jar
>
>
> Executing a composite operation fails when adding a datasource.
> Stack Trace:
> {code}
> 08:38:49,787 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) JBAS014612: Operation ("add") failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "ds-test")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.ds-test 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.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [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.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1422) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 	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 issues at jboss.org  Fri Jan 17 13:32:32 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Fri, 17 Jan 2014 13:32:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-49) Improve Drools project to
 support deployment on JBoss Fuse (Apache Karaf) platform
In-Reply-To: <JIRA.12485427.1361533796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485427.1361533796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485427.1361533796000.49907.1389983552952@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard resolved DROOLS-49.
-------------------------------------

    Resolution: Done

    
> Improve Drools project to support deployment on JBoss Fuse (Apache Karaf) platform
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-49
>                 URL: https://issues.jboss.org/browse/DROOLS-49
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>
> Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
> In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
> Description of work already done
> 1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
> 2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
> 3) Create a itest project validating approach on Karaf with pax-exam & drools 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 issues at jboss.org  Fri Jan 17 13:32:33 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Fri, 17 Jan 2014 13:32:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-55) drools-spring module should
 not contain package org.drools.grid
In-Reply-To: <JIRA.12485676.1361898044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485676.1361898044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485676.1361898044000.49910.1389983553103@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Moulliard resolved DROOLS-55.
-------------------------------------

    Resolution: Done

    
> drools-spring module should not contain package org.drools.grid
> ---------------------------------------------------------------
>
>                 Key: DROOLS-55
>                 URL: https://issues.jboss.org/browse/DROOLS-55
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>
> Current Drools project contains a Grid implementation but it exists into 2 different maven module :
> - drools-spring
> - drools-grid
> This creates a lot of confusion for incoming users as they does not know which one to be used (apparently drools-grid is deprecated and should be removed).
> BTW, id the correct one to be used is contained into drools-spring, then we should move out this code and place it in a maven module packaged according to convention org.drools.artifactId
> This cleanup will also simplify OSGI transformation of Drools project as packages to be imported / exported will be clearly defined

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 16:14:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 17 Jan 2014 16:14:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-822) MBean created via
 EAR/META-INF/jboss-service.xml from class defined in JBoss module gets
 wrong TCCL
In-Reply-To: <JIRA.12475332.1348586276000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475332.1348586276000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475332.1348586276000.50022.1389993273291@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-822:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1054972

    
> MBean created via EAR/META-INF/jboss-service.xml from class defined in JBoss module gets wrong TCCL
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-822
>                 URL: https://issues.jboss.org/browse/WFLY-822
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, Server
>         Environment: Java 6u31
>            Reporter: Zachary Bedell
>            Assignee: jaikiran pai
>              Labels: classloader, mbean, modules
>             Fix For: 8.0.0.Alpha3
>
>         Attachments: SarTcclTst.tbz
>
>
> When an MBean is loaded from jboss-service.xml within an EAR, the TCCL should point to the EAR deployment so that config files and other resources can be classloaded from the EAR.  Under JBoss 7.1.1.Final, the TCCL in a module loaded MBean's start() method is the module's ClassLoader.  No reference to the EAR deployment's classloader is available, thus EAR resources are not available within the MBean.
> It appears that org.jboss.as.service.AbstractService::invokeLifecycleMethod() incorrectly sets the TCCL to the module's defining classloader rather than the EAR's:
> {{{
> protected void invokeLifecycleMethod(final Method method) throws InvocationTargetException, IllegalAccessException {
>         if (method != null) {
>             final ClassLoader old = SecurityActions.setThreadContextClassLoader(mBeanInstance.getClass().getClassLoader());
>             try {
>                 method.invoke(mBeanInstance);
>             } finally {
>                 SecurityActions.resetThreadContextClassLoader(old);
>             }
>         }
>     }
> }}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 17:52:32 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Fri, 17 Jan 2014 17:52:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1771) Replace Exposed{Input,
 Output}Stream with ByteArray{Input, Output}Stream
In-Reply-To: <JIRA.12529680.1389957103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529680.1389957103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529680.1389957103000.50054.1389999152734@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sanne Grinovero updated JGRP-1771:
----------------------------------

    Description: 
Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
Same thing for sending a message or message list.

SOLUTION:
* Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
*** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
* Similar solution for sending of messages / message lists

  was:
Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
The problem is that DataInputStream creates an 80 byte buffer for every creation.
Same thing for sending a message or message list.

SOLUTION:
* Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
*** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
* Similar solution for sending of messages / message lists


    
> Replace Exposed{Input,Output}Stream with ByteArray{Input,Output}Stream
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1771
>                 URL: https://issues.jboss.org/browse/JGRP-1771
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
> The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
> Same thing for sending a message or message list.
> SOLUTION:
> * Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
> ** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
> *** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
> * Similar solution for sending of messages / message lists

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 17:56:32 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Fri, 17 Jan 2014 17:56:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1774) Avoid buffer allocations when
 encoding a long for appending to another buffer
In-Reply-To: <JIRA.12529729.1389999342197@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529729.1389999342197@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529729.1389999342197.50056.1389999392670@jira02.app.mwc.hst.phx2.redhat.com>

Sanne Grinovero created JGRP-1774:
-------------------------------------

             Summary: Avoid buffer allocations when encoding a long for appending to another buffer
                 Key: JGRP-1774
                 URL: https://issues.jboss.org/browse/JGRP-1774
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Sanne Grinovero
            Assignee: Sanne Grinovero
             Fix For: 3.5


When a long gets encoded, a function is used which returns a {code}byte[]{code}.
There are some hot methods which invoke this encoding, to then append the buffer's content into a _DataOutput_. Especially for the case of these hot methods we should rather have the function write the encoded form directly into the _DataOutput_.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 17 23:16:33 2014
From: issues at jboss.org (Vinod Kiran Paidimarry (JIRA))
Date: Fri, 17 Jan 2014 23:16:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-405) Kie-camel tests should not
 use InternalSpringUtils.
In-Reply-To: <JIRA.12529730.1390018557291@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529730.1390018557291@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529730.1390018557291.50136.1390018593802@jira02.app.mwc.hst.phx2.redhat.com>

Vinod Kiran Paidimarry created DROOLS-405:
---------------------------------------------

             Summary: Kie-camel tests should not use InternalSpringUtils.
                 Key: DROOLS-405
                 URL: https://issues.jboss.org/browse/DROOLS-405
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Vinod Kiran Paidimarry
            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 issues at jboss.org  Sat Jan 18 00:04:32 2014
From: issues at jboss.org (Vinod Kiran Paidimarry (JIRA))
Date: Sat, 18 Jan 2014 00:04:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-405) Kie-camel tests should not
 use InternalSpringUtils.
In-Reply-To: <JIRA.12529730.1390018557000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529730.1390018557000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529730.1390018557000.50139.1390021472789@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vinod Kiran Paidimarry updated DROOLS-405:
------------------------------------------

    Git Pull Request: https://github.com/droolsjbpm/droolsjbpm-integration/pull/79  (was: https://github.com/droolsjbpm/droolsjbpm-integration/pull/76)

    
> Kie-camel tests should not use InternalSpringUtils.
> ---------------------------------------------------
>
>                 Key: DROOLS-405
>                 URL: https://issues.jboss.org/browse/DROOLS-405
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Vinod Kiran Paidimarry
>            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 issues at jboss.org  Sat Jan 18 17:35:28 2014
From: issues at jboss.org (Darko Palic (JIRA))
Date: Sat, 18 Jan 2014 17:35:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-130) Cygwin,
 add-user.sh and error "JBAS015232: Aucune java.io.Console
 disponible pour interagir avec l'utilisateur."
In-Reply-To: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483614.1359396502000.43.1390084528818@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936815#comment-12936815 ] 

Darko Palic commented on WFLY-130:
----------------------------------

Hi Darran,
I am willing to provide help and support. But I cannot see a problem in the code. So how can I help you with the wildfly CR1 runtime, to figure out the bug?

Hint: there is no issue with cygwin 32bit and java 32bit. But both I am getting the exception.
                
> Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-130
>                 URL: https://issues.jboss.org/browse/WFLY-130
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>         Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
>            Reporter: Bernard Giroud
>            Assignee: Darran Lofthouse
>              Labels: as7, management
>             Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
>     cygwin = true;
> {code}
> It should read:
> {code}
>     cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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 issues at jboss.org  Sun Jan 19 01:13:28 2014
From: issues at jboss.org (Mohit Srivastava (JIRA))
Date: Sun, 19 Jan 2014 01:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-406) Memory Leak during drool
 workbench deployment on tomcat 7
In-Reply-To: <JIRA.12529818.1390111947082@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529818.1390111947082@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529818.1390111947082.63.1390112008726@jira02.app.mwc.hst.phx2.redhat.com>

Mohit Srivastava created DROOLS-406:
---------------------------------------

             Summary: Memory Leak during drool workbench deployment on tomcat 7
                 Key: DROOLS-406
                 URL: https://issues.jboss.org/browse/DROOLS-406
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final
         Environment: OS: Centos 6.5
            Reporter: Mohit Srivastava
            Assignee: Mark Proctor


After restarting the service fro tomcat manager causes following error:

Jan 18, 2014 8:17:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/drools-wb-6.0.1.Final-tomcat7.0] appears to have started a thread named [pool-4-thread-1] but has failed to stop it. This is very likely to create a memory leak.
Jan 18, 2014 8:17:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/drools-wb-6.0.1.Final-tomcat7.0] appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak.
Jan 18, 2014 8:17:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/drools-wb-6.0.1.Final-tomcat7.0] appears to have started a thread named [pool-7-thread-1] but has failed to stop it. This is very likely to create a memory leak.
Jan 18, 2014 8:17:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/drools-wb-6.0.1.Final-tomcat7.0] appears to have started a thread named [com.google.inject.internal.util.$Finalizer] but has failed to stop it. This is very likely to create a memory leak.
Jan 18, 2014 8:17:51 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/drools-wb-6.0.1.Final-tomcat7.0] appears to have started a thread named [Thread-5] but has failed to stop it. This is very likely to create a memory leak.

Full trace: http://pastebin.com/75tAuZvu

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 19 07:47:28 2014
From: issues at jboss.org (jansi senthil (JIRA))
Date: Sun, 19 Jan 2014 07:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5075) Local ejb calls are always
	anonymous
In-Reply-To: <JIRA.12469525.1340776898000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469525.1340776898000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469525.1340776898000.71.1390135648975@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936818#comment-12936818 ] 

jansi senthil commented on AS7-5075:
------------------------------------

HI, i am having an similar issue. I created an web application. This invokes an local EJB. Application is having JAAS security. But in my EJB, when i give sessionCtx.getCallerPrincipal().getName(), it is always returning anonymous.

Any clue.

User is authenticated based on my application users. In standalone.xml, i have given as 

 <subsystem xmlns="urn:jboss:domain:remoting:1.1">
            <connector name="remoting-connector" socket-binding="remoting" security-realm="other"/>
        </subsystem>

<security-domain name="other" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="RealmUsersRoles" flag="required">
                            <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
                            <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
                            <module-option name="realm" value="ApplicationRealm"/>
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>

Any help in this regard is appreciated. Thanks
                
> Local ejb calls are always anonymous
> ------------------------------------
>
>                 Key: AS7-5075
>                 URL: https://issues.jboss.org/browse/AS7-5075
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Michael Gronau
>            Assignee: jaikiran pai
>              Labels: ejb, local, remote
>
> Calling an ejb from within a mbean service for example is always running under 'anonymous' user even with a JAAS login before the invocation.
> Debugging has shown that only a correct security context is created by the SimpleSecurityManager when the call comes from a remote client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 19 07:49:29 2014
From: issues at jboss.org (jansi senthil (JIRA))
Date: Sun, 19 Jan 2014 07:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5075) Local ejb calls are always
	anonymous
In-Reply-To: <JIRA.12469525.1340776898000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469525.1340776898000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469525.1340776898000.78.1390135769001@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936818#comment-12936818 ] 

jansi senthil edited comment on AS7-5075 at 1/19/14 7:47 AM:
-------------------------------------------------------------

HI, i am having an similar issue. I created an web application. This invokes an local EJB. Application is having JAAS security. But in my EJB, when i give sessionCtx.getCallerPrincipal().getName(), it is always returning anonymous.

Any clue.

User is authenticated based on my application users. In standalone.xml, i have given as 

 <subsystem xmlns="urn:jboss:domain:remoting:1.1">
            <connector name="remoting-connector" socket-binding="remoting" security-realm="other"/>
        </subsystem>

<security-domain name="other" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="RealmUsersRoles" flag="required">
                            <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
                            <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
                            <module-option name="realm" value="ApplicationRealm"/>
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>


In my EJB SB, i have given "@SecurityDomain("other")" also.
Any help in this regard is appreciated. Thanks
                
      was (Author: shivjan0610):
    HI, i am having an similar issue. I created an web application. This invokes an local EJB. Application is having JAAS security. But in my EJB, when i give sessionCtx.getCallerPrincipal().getName(), it is always returning anonymous.

Any clue.

User is authenticated based on my application users. In standalone.xml, i have given as 

 <subsystem xmlns="urn:jboss:domain:remoting:1.1">
            <connector name="remoting-connector" socket-binding="remoting" security-realm="other"/>
        </subsystem>

<security-domain name="other" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="RealmUsersRoles" flag="required">
                            <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>
                            <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>
                            <module-option name="realm" value="ApplicationRealm"/>
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>

Any help in this regard is appreciated. Thanks
                  
> Local ejb calls are always anonymous
> ------------------------------------
>
>                 Key: AS7-5075
>                 URL: https://issues.jboss.org/browse/AS7-5075
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Michael Gronau
>            Assignee: jaikiran pai
>              Labels: ejb, local, remote
>
> Calling an ejb from within a mbean service for example is always running under 'anonymous' user even with a JAAS login before the invocation.
> Debugging has shown that only a correct security context is created by the SimpleSecurityManager when the call comes from a remote client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 19 08:03:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 19 Jan 2014 08:03:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5075) Local ejb calls are always
	anonymous
In-Reply-To: <JIRA.12469525.1340776898000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469525.1340776898000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469525.1340776898000.85.1390136608994@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936819#comment-12936819 ] 

Stuart Douglas commented on AS7-5075:
-------------------------------------

Please use the forums to ask for help
                
> Local ejb calls are always anonymous
> ------------------------------------
>
>                 Key: AS7-5075
>                 URL: https://issues.jboss.org/browse/AS7-5075
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Michael Gronau
>            Assignee: jaikiran pai
>              Labels: ejb, local, remote
>
> Calling an ejb from within a mbean service for example is always running under 'anonymous' user even with a JAAS login before the invocation.
> Debugging has shown that only a correct security context is created by the SimpleSecurityManager when the call comes from a remote client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 19 11:03:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jan 2014 11:03:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-407)
 kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
 without drools-reteoo.jar in the classpath should fail fast instead of a
 warning
In-Reply-To: <JIRA.12529821.1390147304138@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529821.1390147304138@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529821.1390147304138.98.1390147408685@jira02.app.mwc.hst.phx2.redhat.com>

Geoffrey De Smet created DROOLS-407:
---------------------------------------

             Summary: kieBaseConfiguration.setOption(RuleEngineOption.RETEOO); without drools-reteoo.jar in the classpath should fail fast instead of a warning
                 Key: DROOLS-407
                 URL: https://issues.jboss.org/browse/DROOLS-407
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
            Reporter: Geoffrey De Smet
            Assignee: Mark Proctor


If a user explicitly asks for RETEOO
  kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);

and drools-reteoo.jar is not on the classpath, it should crash and burn.

Not happily continue while logging a warning (which might not be seen).

Lost a bunch of benchmarks due to this and lead invalid conclusions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 19 14:15:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sun, 19 Jan 2014 14:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2439) Arquillian Wildfly Managed -
 support exploded mode
In-Reply-To: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518015.1383653230000.106.1390158929087@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936822#comment-12936822 ] 

Tomaz Cerar commented on WFLY-2439:
-----------------------------------

I really don't see any use for this? 
Arquillian is a test tool, that deploys application as part of test lifecycle. 
Said that there is no use in having exploded deployments if you are creating them with ShrinkWrap.
Am I missing something?
                
> Arquillian Wildfly Managed - support exploded mode
> --------------------------------------------------
>
>                 Key: WFLY-2439
>                 URL: https://issues.jboss.org/browse/WFLY-2439
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Zizka
>              Labels: arquillian
>
> Arquillian WildFly managed container currently doesn't support exploded mode deployment. JBDS supports it through moving the files to the standalone/deployments dir. It would be nice if we could add some tests covering this to the WildFly testsuite.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 19 17:01:28 2014
From: issues at jboss.org (Tomek Adamski (JIRA))
Date: Sun, 19 Jan 2014 17:01:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-681) Using "depends
 optional-attribute-name" tag towards a MBean ObjectName does not work
In-Reply-To: <JIRA.12476640.1349944801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12476640.1349944801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12476640.1349944801000.114.1390168888627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomek Adamski reassigned WFLY-681:
----------------------------------

    Assignee: Tomek Adamski

    
> Using "depends optional-attribute-name" tag towards a MBean ObjectName does not work
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-681
>                 URL: https://issues.jboss.org/browse/WFLY-681
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Anders Welen
>            Assignee: Tomek Adamski
>             Fix For: Awaiting Volunteers
>
>
> Using "depends optional-attribute-name" tag towards a MBean ObjectName produces the following exception at deployment:
> {noformat} 
> 10:34:54,034 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.mbean.service.test:service=Test2.create: org.jboss.msc.service.StartException in service jboss.mbean.service.test:service=Test2.create: Failed to start service
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [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_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
>         at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:102) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1549) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl.access$1900(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1780) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1741) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         ... 3 more
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:92) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         ... 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 issues at jboss.org  Mon Jan 20 02:51:28 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Mon, 20 Jan 2014 02:51:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2488) Adding a datasource fails in
 a composite operation
In-Reply-To: <JIRA.12524806.1384188210000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524806.1384188210000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524806.1384188210000.220.1390204288853@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936838#comment-12936838 ] 

Stefano Maestri commented on WFLY-2488:
---------------------------------------

In 8.x default for enabled is changed and it's now true. Your composite operation will work if first operation explicit declare enabled=false. Note that this composite operation is really needed w/ 8.x only if you have ore or more operations between those 2 adding connection-properties. New description for resource should be already correct

If it makes sense, please close the issue. If you have more questions/problems just back to me here or in IRC

                
> Adding a datasource fails in a composite operation
> --------------------------------------------------
>
>                 Key: WFLY-2488
>                 URL: https://issues.jboss.org/browse/WFLY-2488
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Perkins
>            Assignee: Stefano Maestri
>         Attachments: wfly2488-sources.jar, wfly2488.jar
>
>
> Executing a composite operation fails when adding a datasource.
> Stack Trace:
> {code}
> 08:38:49,787 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) JBAS014612: Operation ("add") failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "ds-test")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.ds-test 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.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [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.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1422) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 	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 issues at jboss.org  Mon Jan 20 04:35:29 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 20 Jan 2014 04:35:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2427) Launcher API
In-Reply-To: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509240.1383251005000.361.1390210529167@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936854#comment-12936854 ] 

Max Rydahl Andersen commented on WFLY-2427:
-------------------------------------------

If it calls standalone.bat directly it is not really useful for us nor arquillian I believe since that prevents control over the actual launched process - which is needed to reliably kill the process under windows in case of run-away java process (i.e. you already have a server running on that management port you can no longer tell the just launched wildfly process to stop = user have to manually to kill the process)

This is the primary reason why we don't use any *.bat nor *.sh launching if we can avoid it.


                
> Launcher API
> ------------
>
>                 Key: WFLY-2427
>                 URL: https://issues.jboss.org/browse/WFLY-2427
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. 
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. 
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -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 "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.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 issues at jboss.org  Mon Jan 20 04:41:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 20 Jan 2014 04:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-407)
 kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
 without drools-reteoo.jar in the classpath should fail fast instead of a
 warning
In-Reply-To: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529821.1390147304000.375.1390210888892@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936858#comment-12936858 ] 

Geoffrey De Smet commented on DROOLS-407:
-----------------------------------------

This is like going to the restaurant and ordering a steak.
And then the waiter brings you salmon because he's out of steaks.

If there's not steaks, I want the waiter to come back and tell me there are no steaks.
Not just bring me something else which he tries to pass off as steak.
                
> kieBaseConfiguration.setOption(RuleEngineOption.RETEOO); without drools-reteoo.jar in the classpath should fail fast instead of a warning
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-407
>                 URL: https://issues.jboss.org/browse/DROOLS-407
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Mark Proctor
>
> If a user explicitly asks for RETEOO
>   kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
> and drools-reteoo.jar is not on the classpath, it should crash and burn.
> Not happily continue while logging a warning (which might not be seen).
> Lost a bunch of benchmarks due to this and lead invalid conclusions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 04:45:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 20 Jan 2014 04:45:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-407)
 kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
 without drools-reteoo.jar in the classpath should fail fast instead of a
 warning
In-Reply-To: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529821.1390147304000.386.1390211128626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-407:
------------------------------------

    Description: 
If a user explicitly asks for RETEOO
  kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);

and drools-reteoo.jar is not on the classpath, it should crash and burn.

Not happily continue while logging a warning (which are often not be seen).

  was:
If a user explicitly asks for RETEOO
  kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);

and drools-reteoo.jar is not on the classpath, it should crash and burn.

Not happily continue while logging a warning (which might not be seen).

Lost a bunch of benchmarks due to this and lead invalid conclusions.


    
> kieBaseConfiguration.setOption(RuleEngineOption.RETEOO); without drools-reteoo.jar in the classpath should fail fast instead of a warning
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-407
>                 URL: https://issues.jboss.org/browse/DROOLS-407
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Mark Proctor
>
> If a user explicitly asks for RETEOO
>   kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
> and drools-reteoo.jar is not on the classpath, it should crash and burn.
> Not happily continue while logging a warning (which are often not be seen).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 04:45:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 20 Jan 2014 04:45:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-407)
 kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
 without drools-reteoo.jar in the classpath should fail fast instead of a
 warning
In-Reply-To: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529821.1390147304000.389.1390211128786@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-407:
------------------------------------

    Description: 
If a user explicitly asks for RETEOO
  kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);

and drools-reteoo.jar is not on the classpath, it should crash and burn.

Not happily continue while logging a warning (which are often not seen).

  was:
If a user explicitly asks for RETEOO
  kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);

and drools-reteoo.jar is not on the classpath, it should crash and burn.

Not happily continue while logging a warning (which are often not be seen).


    
> kieBaseConfiguration.setOption(RuleEngineOption.RETEOO); without drools-reteoo.jar in the classpath should fail fast instead of a warning
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-407
>                 URL: https://issues.jboss.org/browse/DROOLS-407
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Mark Proctor
>
> If a user explicitly asks for RETEOO
>   kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
> and drools-reteoo.jar is not on the classpath, it should crash and burn.
> Not happily continue while logging a warning (which are often not seen).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 04:47:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 20 Jan 2014 04:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-407)
 kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
 without drools-reteoo.jar in the classpath should fail fast instead of a
 warning
In-Reply-To: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529821.1390147304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529821.1390147304000.395.1390211248684@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936858#comment-12936858 ] 

Geoffrey De Smet edited comment on DROOLS-407 at 1/20/14 4:47 AM:
------------------------------------------------------------------

This is like going to the restaurant and ordering a steak.
And then the waiter brings you salmon because he's out of steaks.

If there are no steaks, I want the waiter to come back and tell me there are no steaks.
Not just bring me something else which he tries to pass off as steak.
                
      was (Author: ge0ffrey):
    This is like going to the restaurant and ordering a steak.
And then the waiter brings you salmon because he's out of steaks.

If there's not steaks, I want the waiter to come back and tell me there are no steaks.
Not just bring me something else which he tries to pass off as steak.
                  
> kieBaseConfiguration.setOption(RuleEngineOption.RETEOO); without drools-reteoo.jar in the classpath should fail fast instead of a warning
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-407
>                 URL: https://issues.jboss.org/browse/DROOLS-407
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Mark Proctor
>
> If a user explicitly asks for RETEOO
>   kieBaseConfiguration.setOption(RuleEngineOption.RETEOO);
> and drools-reteoo.jar is not on the classpath, it should crash and burn.
> Not happily continue while logging a warning (which are often not seen).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 04:57:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Jan 2014 04:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2775) Startup exception when
 setting "enabled-cipher-suites" attribute in standalone.xml
In-Reply-To: <JIRA.12529831.1390211122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529831.1390211122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529831.1390211122000.405.1390211848935@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved UNDERTOW-174 to WFLY-2775:
-----------------------------------------------

              Project: WildFly  (was: Undertow)
                  Key: WFLY-2775  (was: UNDERTOW-174)
    Affects Version/s: 8.0.0.CR1
                           (was: 1.0.0.Beta30)
          Component/s: Web (Undertow)
                           (was: Core)
             Security: Public

    
> Startup exception when setting "enabled-cipher-suites" attribute in standalone.xml
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2775
>                 URL: https://issues.jboss.org/browse/WFLY-2775
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Wildfly 8.0.0.CR1
>            Reporter: Andrew Scully
>            Assignee: Stuart Douglas
>              Labels: config, startup
>
> See: http://lists.jboss.org/pipermail/undertow-dev/2014-January/000670.html
> I'm having an issue when configuring a HTTPS listener for Undertow via the JBOSS standalone.xml method.
> I get the following exception on startup:
> 2014-01-16 16:00:34,521 ERROR [org.jboss.msc.service.fail](MSC service thread 1-9) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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:724)
> Caused by: java.lang.ClassCastException: Not a sequence
> 	at org.xnio.SequenceOption.cast(SequenceOption.java:57)
> 	at org.xnio.SequenceOption.cast(SequenceOption.java:31)
> 	at org.xnio.OptionMap.get(OptionMap.java:64)
> 	at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)
> 	at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)
> 	at org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)
> 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> My JBOSS Undertow configuration looks like this:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">       
>             <buffer-caches>
>                 <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
>             </buffer-caches>
>             <server name="default-server">            	
>                 <ajp-listener name="ajp" socket-binding="ajp"/>
>                 <http-listener name="http" socket-binding="http"/>
>                 <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV" />
>                 <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content"/>
>                     <access-log directory="${jboss.server.base.dir}/log" prefix="localhost_access_log."/>
>                 </host>
>             </server>
>             <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
>                 <jsp-config x-powered-by="false"/>
>                 <persistent-sessions/>
>             </servlet-container>
>             <handlers>
>                 <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
>             </handlers>
>         </subsystem>
> By process of elimination, I've found that removing the "enabled-cipher-suites" attribute makes the problem go away, so it appears this is the culprit.
> The value I'm using for this attribute has simply been copied from our jboss-web configuration, previously "cipher-suite".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 04:59:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Jan 2014 04:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2775) Startup exception when
 setting "enabled-cipher-suites" attribute in standalone.xml
In-Reply-To: <JIRA.12529831.1390211122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529831.1390211122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529831.1390211122000.408.1390211968565@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2775:
------------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> Startup exception when setting "enabled-cipher-suites" attribute in standalone.xml
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2775
>                 URL: https://issues.jboss.org/browse/WFLY-2775
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Wildfly 8.0.0.CR1
>            Reporter: Andrew Scully
>            Assignee: Tomaz Cerar
>              Labels: config, startup
>
> See: http://lists.jboss.org/pipermail/undertow-dev/2014-January/000670.html
> I'm having an issue when configuring a HTTPS listener for Undertow via the JBOSS standalone.xml method.
> I get the following exception on startup:
> 2014-01-16 16:00:34,521 ERROR [org.jboss.msc.service.fail](MSC service thread 1-9) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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:724)
> Caused by: java.lang.ClassCastException: Not a sequence
> 	at org.xnio.SequenceOption.cast(SequenceOption.java:57)
> 	at org.xnio.SequenceOption.cast(SequenceOption.java:31)
> 	at org.xnio.OptionMap.get(OptionMap.java:64)
> 	at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)
> 	at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)
> 	at org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)
> 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> My JBOSS Undertow configuration looks like this:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">       
>             <buffer-caches>
>                 <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
>             </buffer-caches>
>             <server name="default-server">            	
>                 <ajp-listener name="ajp" socket-binding="ajp"/>
>                 <http-listener name="http" socket-binding="http"/>
>                 <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV" />
>                 <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content"/>
>                     <access-log directory="${jboss.server.base.dir}/log" prefix="localhost_access_log."/>
>                 </host>
>             </server>
>             <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
>                 <jsp-config x-powered-by="false"/>
>                 <persistent-sessions/>
>             </servlet-container>
>             <handlers>
>                 <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
>             </handlers>
>         </subsystem>
> By process of elimination, I've found that removing the "enabled-cipher-suites" attribute makes the problem go away, so it appears this is the culprit.
> The value I'm using for this attribute has simply been copied from our jboss-web configuration, previously "cipher-suite".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 05:13:28 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 20 Jan 2014 05:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2776) Upgrade to JBossWS 4.3.0.Beta1
In-Reply-To: <JIRA.12529833.1390212725425@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529833.1390212725425@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529833.1390212725425.448.1390212808562@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-2776:
-------------------------------------

             Summary: Upgrade to JBossWS 4.3.0.Beta1
                 Key: WFLY-2776
                 URL: https://issues.jboss.org/browse/WFLY-2776
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 9.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 issues at jboss.org  Mon Jan 20 05:23:28 2014
From: issues at jboss.org (Risto Oikarinen (JIRA))
Date: Mon, 20 Jan 2014 05:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1775)
 Relay2Test.testQueueingAndForwarding fails randomly
In-Reply-To: <JIRA.12529835.1390213392002@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529835.1390213392002@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529835.1390213392002.459.1390213408968@jira02.app.mwc.hst.phx2.redhat.com>

Risto Oikarinen created JGRP-1775:
-------------------------------------

             Summary: Relay2Test.testQueueingAndForwarding fails randomly
                 Key: JGRP-1775
                 URL: https://issues.jboss.org/browse/JGRP-1775
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.3.5
            Reporter: Risto Oikarinen
            Assignee: Bela Ban


Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
{code:java}
    public void testQueueInLoop() throws Exception {
            for ( int i = 0; i < 1000; ++i) {
                         testQueueingAndForwarding();
                         destroy();
            }
    }
{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 issues at jboss.org  Mon Jan 20 05:25:29 2014
From: issues at jboss.org (Risto Oikarinen (JIRA))
Date: Mon, 20 Jan 2014 05:25:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1775)
 Relay2Test.testQueueingAndForwarding fails randomly
In-Reply-To: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529835.1390213392000.469.1390213529054@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Risto Oikarinen updated JGRP-1775:
----------------------------------

    Attachment: relay2test_fails_randomly_log.txt


Trace log added.
                
> Relay2Test.testQueueingAndForwarding fails randomly
> ---------------------------------------------------
>
>                 Key: JGRP-1775
>                 URL: https://issues.jboss.org/browse/JGRP-1775
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.5
>            Reporter: Risto Oikarinen
>            Assignee: Bela Ban
>         Attachments: relay2test_fails_randomly_log.txt
>
>
> Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
> {code:java}
>     public void testQueueInLoop() throws Exception {
>             for ( int i = 0; i < 1000; ++i) {
>                          testQueueingAndForwarding();
>                          destroy();
>             }
>     }
> {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 issues at jboss.org  Mon Jan 20 05:27:28 2014
From: issues at jboss.org (Risto Oikarinen (JIRA))
Date: Mon, 20 Jan 2014 05:27:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1775)
 Relay2Test.testQueueingAndForwarding fails randomly
In-Reply-To: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529835.1390213392000.474.1390213648695@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Risto Oikarinen updated JGRP-1775:
----------------------------------

    Description: 
Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
{code:java}
public void testQueueInLoop() throws Exception {
    for ( int i = 0; i < 1000; ++i) {
        testQueueingAndForwarding();
        destroy();
    }
}
{code}


  was:
Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
{code:java}
    public void testQueueInLoop() throws Exception {
            for ( int i = 0; i < 1000; ++i) {
                         testQueueingAndForwarding();
                         destroy();
            }
    }
{code}



    
> Relay2Test.testQueueingAndForwarding fails randomly
> ---------------------------------------------------
>
>                 Key: JGRP-1775
>                 URL: https://issues.jboss.org/browse/JGRP-1775
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.5
>            Reporter: Risto Oikarinen
>            Assignee: Bela Ban
>         Attachments: relay2test_fails_randomly_log.txt
>
>
> Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
> {code:java}
> public void testQueueInLoop() throws Exception {
>     for ( int i = 0; i < 1000; ++i) {
>         testQueueingAndForwarding();
>         destroy();
>     }
> }
> {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 issues at jboss.org  Mon Jan 20 05:31:28 2014
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 20 Jan 2014 05:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2777) JNDI external context binding
 doesn't properly set a module class loader
In-Reply-To: <JIRA.12529837.1390213800617@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529837.1390213800617@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529837.1390213800617.488.1390213888617@jira02.app.mwc.hst.phx2.redhat.com>

Ivo Studensky created WFLY-2777:
-----------------------------------

             Summary: JNDI external context binding doesn't properly set a module class loader
                 Key: WFLY-2777
                 URL: https://issues.jboss.org/browse/WFLY-2777
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: 8.0.0.CR1
            Reporter: Ivo Studensky
            Assignee: Ivo Studensky
             Fix For: 8.0.0.Final


The current implementation of JNDI external context binding takes a module class loader if based by a module for loading a initialContextClassName only (note that this initialContextClassName is one of InitialContext, InitialDirContext or InitialLdapContext). While it rather needs to switch TCCL to the module class loader to be available when trying to get a new instance of it at line 87, see the snippet below. As this is the moment when it constructs a new initial context from a factory class given by environment properties.

{code:java|title=naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java}
83             Module module = Module.getBootModuleLoader().loadModule(ModuleIdentifier.fromString(initialContextModule));
84             loader = module.getClassLoader();
85             initialContextClass = Class.forName(initialContextClassName, true, module.getClassLoader());
86             Constructor ctor = initialContextClass.getConstructor(Hashtable.class);
87             context = (Context) ctor.newInstance(newEnvironment);
{code}
Due to this issue the binding fails with an exception as follows:
{noformat}
17:02:46,740 ERROR [stderr] (default task-1) Caused by: java.lang.reflect.InvocationTargetException
17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
17:02:46,741 ERROR [stderr] (default task-1)   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
17:02:46,741 ERROR [stderr] (default task-1)   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:46)
17:02:46,743 ERROR [stderr] (default task-1)   at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
17:02:46,743 ERROR [stderr] (default task-1)   ... 36 more
17:02:46,744 ERROR [stderr] (default task-1) Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory from classloader ModuleClassLoader for Module &quot;deployment.messagesender.war:main&quot; from Service Module Loader
17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.directory.InitialDirContext.&lt;init&gt;(InitialDirContext.java:101)
17:02:46,745 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.&lt;init&gt;(InitialContext.java:90)
17:02:46,746 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.init(InitialContext.java:242)
17:02:46,747 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
17:02:46,747 ERROR [stderr] (default task-1)   ... 43 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 issues at jboss.org  Mon Jan 20 05:47:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Mon, 20 Jan 2014 05:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792414@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792414@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792414.509.1390214848747@jira02.app.mwc.hst.phx2.redhat.com>

Matthias Richter created WFLY-2778:
--------------------------------------

             Summary: CPU load at 99% with WildFly 8 CR1
                 Key: WFLY-2778
                 URL: https://issues.jboss.org/browse/WFLY-2778
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
         Environment: $ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

WildFly 8.0.0.CR1
XNIO version 3.2.0.Beta4
Undertow 1.0.0.Beta30
            Reporter: Matthias Richter
            Assignee: Stuart Douglas


After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.

https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 05:51:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 05:51:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1775)
 Relay2Test.testQueueingAndForwarding fails randomly
In-Reply-To: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529835.1390213392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529835.1390213392000.516.1390215088557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1775:
---------------------------

    Fix Version/s: 3.5
         Priority: Minor  (was: Major)


This test doesn't exist anymore in 3.5, as the underlying implementation changed (route status).
                
> Relay2Test.testQueueingAndForwarding fails randomly
> ---------------------------------------------------
>
>                 Key: JGRP-1775
>                 URL: https://issues.jboss.org/browse/JGRP-1775
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.5
>            Reporter: Risto Oikarinen
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>         Attachments: relay2test_fails_randomly_log.txt
>
>
> Relay2Test.testQueueingAndForwarding seems to be failing randomly. I was able to reproduce this with the following test:
> {code:java}
> public void testQueueInLoop() throws Exception {
>     for ( int i = 0; i < 1000; ++i) {
>         testQueueingAndForwarding();
>         destroy();
>     }
> }
> {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 issues at jboss.org  Mon Jan 20 05:55:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Jan 2014 05:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.522.1390215328586@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2778:
---------------------------------

    Priority: Blocker  (was: Major)

    
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 05:59:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Mon, 20 Jan 2014 05:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.527.1390215568595@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936879#comment-12936879 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Stuart, if I can assist you any further please let me know.

Thanks for your work!
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:01:32 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Jan 2014 06:01:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.550.1390215692161@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936881#comment-12936881 ] 

Stuart Douglas commented on WFLY-2778:
--------------------------------------

I few more instances of stack traces could be useful, preferably in text rather than image form. 
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:07:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:07:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1776) RSVP: flag ACKs as OOB and
	DONT_BUNDLE
In-Reply-To: <JIRA.12529842.1390215935037@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529842.1390215935037@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529842.1390215935037.568.1390216048562@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1776:
------------------------------

             Summary: RSVP: flag ACKs as OOB and DONT_BUNDLE
                 Key: JGRP-1776
                 URL: https://issues.jboss.org/browse/JGRP-1776
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Trivial


Otherwise they might get delivered in a batch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:15:30 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Mon, 20 Jan 2014 06:15:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.591.1390216530420@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias Richter updated WFLY-2778:
-----------------------------------

    Attachment: stacktrace-6156.out
                stacktrace-6157.out
                stacktrace-6158.out


Stuart,

here are the stackstraces (sudo jstack -F PID) for three threads each using 33% cpu.

Hope this helps.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:37:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:37:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1777) TP: add more stats
In-Reply-To: <JIRA.12529847.1390217759274@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529847.1390217759274@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529847.1390217759274.618.1390217848523@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1777:
------------------------------

             Summary: TP: add more stats
                 Key: JGRP-1777
                 URL: https://issues.jboss.org/browse/JGRP-1777
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.5


* Number of single messages sent and received (oob, regular ?)
* Number of bundles sent / batches received (oob, regular?)
* Avg batch 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 issues at jboss.org  Mon Jan 20 06:39:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:39:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1778) Flight recorder tests for
	UPerf, MPerf
In-Reply-To: <JIRA.12529848.1390217931602@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529848.1390217931602@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529848.1390217931602.621.1390217968540@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1778:
------------------------------

             Summary: Flight recorder tests for UPerf, MPerf
                 Key: JGRP-1778
                 URL: https://issues.jboss.org/browse/JGRP-1778
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Optional
             Fix For: 3.5


Use flight recorder (available with JDK 7 u40+) to find out memory and CPU pressure points.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:43:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1779) MethodCall: implement
	Streamable
In-Reply-To: <JIRA.12529849.1390218124785@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529849.1390218124785@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529849.1390218124785.626.1390218208558@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1779:
------------------------------

             Summary: MethodCall: implement Streamable
                 Key: JGRP-1779
                 URL: https://issues.jboss.org/browse/JGRP-1779
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor


MethodCall currently only implements Externalizable. By implementing Streamable, marshalling and unmarshalling should be faster, for simple arguments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:43:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1779) MethodCall: implement
	Streamable
In-Reply-To: <JIRA.12529849.1390218124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529849.1390218124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529849.1390218124000.629.1390218208649@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1779:
---------------------------

    Fix Version/s: 3.5

    
> MethodCall: implement Streamable
> --------------------------------
>
>                 Key: JGRP-1779
>                 URL: https://issues.jboss.org/browse/JGRP-1779
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> MethodCall currently only implements Externalizable. By implementing Streamable, marshalling and unmarshalling should be faster, for simple arguments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 06:45:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:45:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1771) Replace Exposed{Input,
 Output}Stream with ByteArray{Input, Output}Stream
In-Reply-To: <JIRA.12529680.1389957103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529680.1389957103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529680.1389957103000.636.1390218328727@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1771:
---------------------------

    Description: 
Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
Same thing for sending a message or message list.

SOLUTION:
* Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
*** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
* Similar solution for sending of messages / message lists
* Also create the corresponding unit tests

  was:
Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
Same thing for sending a message or message list.

SOLUTION:
* Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
*** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
* Similar solution for sending of messages / message lists


    
> Replace Exposed{Input,Output}Stream with ByteArray{Input,Output}Stream
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1771
>                 URL: https://issues.jboss.org/browse/JGRP-1771
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Currently, when reading a message, we create an ExposedByteArrayInputStream and a DataInputStream on top of it. Then we read the message or message list off of the DataInputStream.
> The problem is that DataInputStream creates an 80 byte buffer for every creation, and also an array of 80 chars (additional 160 bytes + array header + pointer).
> Same thing for sending a message or message list.
> SOLUTION:
> * Create a ByteArrayInputStream which implements DataInput and works by reading from the passed in byte array
> ** Eventually, when switching to NIO.2, use a ByteBufferInputStream which works off of NIO ByteBuffers instead of byte arrays
> *** Possibly replace readFrom(DataInput) with readFrom(Buffer) where Buffer implements reading from an NIO ByteBuffer (and possibly also from a simple byte array). Ditto for sending.
> * Similar solution for sending of messages / message lists
> * Also create the corresponding unit 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 issues at jboss.org  Mon Jan 20 06:49:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1780) UDP: remove invocation of
 DatagramSocket.isClosed()
In-Reply-To: <JIRA.12529850.1390218488880@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529850.1390218488880@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529850.1390218488880.640.1390218568521@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1780:
------------------------------

             Summary: UDP: remove invocation of DatagramSocket.isClosed()
                 Key: JGRP-1780
                 URL: https://issues.jboss.org/browse/JGRP-1780
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.5


In UDP, we check whether a datagram socket is closed by invoking {{DatagramSocket.isClosed()}} for every message that's sent. Flight recorder showed that this creates a bit of lock contention as isClosed() is synchronized.
SOLUTION:
* Simply remove the check. If a socket is closed we'll catch the exception anyway and handle 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 issues at jboss.org  Mon Jan 20 06:56:23 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 06:56:23 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1773)
 TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
In-Reply-To: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529686.1389959943000.1464.1390218983035@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937127#comment-12937127 ] 

Bela Ban commented on JGRP-1773:
--------------------------------

[~sannegrinovero] [~pruivo]: not sure I understand what you meant...
There would be a new {{Message.readFrom()} method which skips reading the buffer and instead only sets the offset and length of the pass-in buffer.
                
> TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
> --------------------------------------------------------------------------
>
>                 Key: JGRP-1773
>                 URL: https://issues.jboss.org/browse/JGRP-1773
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When a single message is received, we pass it to the thread pool for parsing, passing a copy of the byte array to the MyHandler runnable.
> The parsing then creates a new Message and calls readFrom(). This method reads the headers and then creates a payload buffer of the size read from the input stream, then copies {{size}} bytes from the input stream to the mesage's payload.
> This is an unneeded copy; as we already have a copy of the byte array, we only need to *reference* the byte array from the message and set the offset and length, saving us one copy of the buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 07:02:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 07:02:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1781) Message: write/read the
 payload last when marshalling
In-Reply-To: <JIRA.12529852.1390219278446@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529852.1390219278446@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529852.1390219278446.1622.1390219349092@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1781:
------------------------------

             Summary: Message: write/read the payload last when marshalling
                 Key: JGRP-1781
                 URL: https://issues.jboss.org/browse/JGRP-1781
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


When (un)marshalling a message, we process the fields in this order:
# Sender and receiver addresses
# Flags
# Payload
# Headers

I'd like to change this to move processing of the payload to the end because
* If payload refers to a different buffer (JGRP-1773), then we don't need to read the bytes, but currently have to skip N bytes to read the headers. If the payload was at the end, this wouldn't be needed
* Once we use NIO.2 and gathering writes, we'd pass a couple of buffers to the socket write and therefore it's simpler if the payload is written last. Ditto for scattering reads.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 07:06:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 07:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1782) Util.objectToByteBuffer() is
	inefficient
In-Reply-To: <JIRA.12529853.1390219484395@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529853.1390219484395@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529853.1390219484395.1629.1390219588547@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1782:
------------------------------

             Summary: Util.objectToByteBuffer() is inefficient
                 Key: JGRP-1782
                 URL: https://issues.jboss.org/browse/JGRP-1782
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.5


When the type is a string, we create 2 copies. Replace this with 1 copy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 07:16:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 07:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1780) UDP: remove invocation of
 DatagramSocket.isClosed()
In-Reply-To: <JIRA.12529850.1390218488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529850.1390218488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529850.1390218488000.1657.1390220189936@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1780.
----------------------------

    Resolution: Done

    
> UDP: remove invocation of DatagramSocket.isClosed()
> ---------------------------------------------------
>
>                 Key: JGRP-1780
>                 URL: https://issues.jboss.org/browse/JGRP-1780
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> In UDP, we check whether a datagram socket is closed by invoking {{DatagramSocket.isClosed()}} for every message that's sent. Flight recorder showed that this creates a bit of lock contention as isClosed() is synchronized.
> SOLUTION:
> * Simply remove the check. If a socket is closed we'll catch the exception anyway and handle 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 issues at jboss.org  Mon Jan 20 07:20:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 20 Jan 2014 07:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-283) EJB timers in cluster and
	failover support
In-Reply-To: <JIRA.12460393.1330513902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460393.1330513902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460393.1330513902000.1681.1390220429612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-283:
--------------------------------

        Fix Version/s: 9.0.0.CR1
                           (was: 8.0.0.CR1)
                           (was: 8.0.0.Final)
    Affects Version/s: 8.0.0.Final

    
> EJB timers in cluster and failover support
> ------------------------------------------
>
>                 Key: WFLY-283
>                 URL: https://issues.jboss.org/browse/WFLY-283
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR1
>
>
> Support for clustered EJB timer service providing failover.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 07:38:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 07:38:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1351) Incorrect exception handling
 in CoreGroupCommunicationService#handle
In-Reply-To: <JIRA.12491886.1368648070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491886.1368648070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491886.1368648070000.1698.1390221509242@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937180#comment-12937180 ] 

RH Bugzilla Integration commented on WFLY-1351:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 963448|https://bugzilla.redhat.com/show_bug.cgi?id=963448] from POST to MODIFIED
                
> Incorrect exception handling in CoreGroupCommunicationService#handle
> --------------------------------------------------------------------
>
>                 Key: WFLY-1351
>                 URL: https://issues.jboss.org/browse/WFLY-1351
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Dennis Reed
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha3
>
>
> org/jboss/as/clustering/impl/CoreGroupCommunicationService#handle catches and hides any internal exceptions, and just returns null instead.
> This breaks callers of CoreGroupCommunicationService when they get a null value where it's not expected (after verifying that the response was not flagged as an exception)
>     java.lang.NullPointerException
>         at org.jboss.as.clustering.lock.AbstractClusterLockSupport.lock(AbstractClusterLockSupport.java:157)
> It also catches an exception from the called method, and returns it as the return value, instead of just throwing it as an exception so it can be properly returned as an exception inside JGroups' RequestCorrelator.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 07:50:29 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Mon, 20 Jan 2014 07:50:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.1721.1390222229037@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937184#comment-12937184 ] 

Karel Piwko commented on WFLY-91:
---------------------------------

Is this going to be included in WF 8.0.0.Final?
                
> Impossible to use "reload" MDR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 08:00:31 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 20 Jan 2014 08:00:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.1758.1390222831694@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937187#comment-12937187 ] 

Tomaz Cerar commented on WFLY-91:
---------------------------------

I think this issue has become irrelevant/out-of-date given that problem is in how test is written and we added lots of functionality to help with writing tests that need to call reload operation.
This problem originates from services not being restartable even they should be, to workaround that fact testsuite is filled with "reload" calls.
                
> Impossible to use "reload" MDR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 08:06:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jan 2014 08:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1774) Avoid buffer allocations when
 encoding a long for appending to another buffer
In-Reply-To: <JIRA.12529729.1389999342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529729.1389999342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529729.1389999342000.1765.1390223188592@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1774:
---------------------------

    Description: 
When a long gets encoded, a function is used which returns a {{byte[]}}.
There are some hot methods which invoke this encoding, to then append the buffer's content into a _DataOutput_. Especially for the case of these hot methods we should rather have the function write the encoded form directly into the _DataOutput_.

  was:
When a long gets encoded, a function is used which returns a {code}byte[]{code}.
There are some hot methods which invoke this encoding, to then append the buffer's content into a _DataOutput_. Especially for the case of these hot methods we should rather have the function write the encoded form directly into the _DataOutput_.


    
> Avoid buffer allocations when encoding a long for appending to another buffer
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1774
>                 URL: https://issues.jboss.org/browse/JGRP-1774
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 3.5
>
>
> When a long gets encoded, a function is used which returns a {{byte[]}}.
> There are some hot methods which invoke this encoding, to then append the buffer's content into a _DataOutput_. Especially for the case of these hot methods we should rather have the function write the encoded form directly into the _DataOutput_.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 08:06:28 2014
From: issues at jboss.org (Jeff Zhang (JIRA))
Date: Mon, 20 Jan 2014 08:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1950) Problems with connector 1.7
In-Reply-To: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499328.1377460254000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499328.1377460254000.1769.1390223188759@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937188#comment-12937188 ] 

Jeff Zhang commented on WFLY-1950:
----------------------------------

The IronJacamar 1.1.3 had been merged into Wildfly, the NPE would be gone.
                
> Problems with connector 1.7
> ---------------------------
>
>                 Key: WFLY-1950
>                 URL: https://issues.jboss.org/browse/WFLY-1950
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Zhang
>         Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO  [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO  [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO  [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO  [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
>         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.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
>         ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
>         at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
>         at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
>         ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
>     Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
>     Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO  [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 08:24:29 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Mon, 20 Jan 2014 08:24:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.1826.1390224269383@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937198#comment-12937198 ] 

Karel Piwko commented on WFLY-91:
---------------------------------

I did some research here and there:

https://github.com/wildfly/wildfly/pull/2086 seems to be already a part of upstream.
https://github.com/wildfly/wildfly/blob/master/arquillian/common/src/main/java/org/jboss/as/arquillian/container/ManagementClient.java#L351

Also, a test using reload via Arquillian - although with some hack loop to wait for connection to be reestablished - https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/JcaMgmtBase.java#L46 is a part of test suite.

The other fix mentioned here - https://github.com/aloubyansky/wildfly/commit/43b40da9cb8a088b758baf1731cb725b8fc6193d - was made a part of WF 8.0.0.Alpha1.

So, I believe this issue can be marked as resolved for 8.0.0.CR1

[~ctomc] do you have any example of that "lots of functionality"? Is this something to be used externally by application devs or is this something that is available only within WF testsuite?
                
> Impossible to use "reload" MDR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 08:26:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 20 Jan 2014 08:26:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2580) keytool-maven-plugin does not
	work on JDK8
In-Reply-To: <JIRA.12526163.1385474426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526163.1385474426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526163.1385474426000.1833.1390224388745@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2580:
------------------------------

    Description: 
JDK8 has changed JarSigner package / class location

upstream issue https://jira.codehaus.org/browse/MKEYTOOL-35

  was:JDK8 has changed JarSigner package / class location


    
> keytool-maven-plugin does not work on JDK8
> ------------------------------------------
>
>                 Key: WFLY-2580
>                 URL: https://issues.jboss.org/browse/WFLY-2580
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Tomaz Cerar
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>
> JDK8 has changed JarSigner package / class location
> upstream issue https://jira.codehaus.org/browse/MKEYTOOL-35

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 08:30:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 20 Jan 2014 08:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.1857.1390224628831@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-91.
-----------------------------

    Resolution: Done


There are uses in our testsuite, mostly in "manualmode" part of testsuite. 
I also know for few uses of this outside of wildfly codebase, but would need to search a bit for it.

                
> Impossible to use "reload" MDR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final, 8.0.0.CR1
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 08:30:30 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 20 Jan 2014 08:30:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" DMR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.1883.1390224630028@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-91:
----------------------------

    Summary: Impossible to use "reload" DMR operation in testsuite run  (was: Impossible to use "reload" MDR operation in testsuite run)

    
> Impossible to use "reload" DMR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 08:32:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 20 Jan 2014 08:32:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2775) Startup exception when
 setting "enabled-cipher-suites" attribute in standalone.xml
In-Reply-To: <JIRA.12529831.1390211122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529831.1390211122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529831.1390211122000.1887.1390224748719@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2775:
------------------------------

    Fix Version/s: 8.0.0.Final

    
> Startup exception when setting "enabled-cipher-suites" attribute in standalone.xml
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2775
>                 URL: https://issues.jboss.org/browse/WFLY-2775
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: Wildfly 8.0.0.CR1
>            Reporter: Andrew Scully
>            Assignee: Tomaz Cerar
>              Labels: config, startup
>             Fix For: 8.0.0.Final
>
>
> See: http://lists.jboss.org/pipermail/undertow-dev/2014-January/000670.html
> I'm having an issue when configuring a HTTPS listener for Undertow via the JBOSS standalone.xml method.
> I get the following exception on startup:
> 2014-01-16 16:00:34,521 ERROR [org.jboss.msc.service.fail](MSC service thread 1-9) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 	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:724)
> Caused by: java.lang.ClassCastException: Not a sequence
> 	at org.xnio.SequenceOption.cast(SequenceOption.java:57)
> 	at org.xnio.SequenceOption.cast(SequenceOption.java:31)
> 	at org.xnio.OptionMap.get(OptionMap.java:64)
> 	at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)
> 	at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)
> 	at org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)
> 	at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	... 3 more
> My JBOSS Undertow configuration looks like this:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">       
>             <buffer-caches>
>                 <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
>             </buffer-caches>
>             <server name="default-server">            	
>                 <ajp-listener name="ajp" socket-binding="ajp"/>
>                 <http-listener name="http" socket-binding="http"/>
>                 <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV" />
>                 <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content"/>
>                     <access-log directory="${jboss.server.base.dir}/log" prefix="localhost_access_log."/>
>                 </host>
>             </server>
>             <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
>                 <jsp-config x-powered-by="false"/>
>                 <persistent-sessions/>
>             </servlet-container>
>             <handlers>
>                 <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
>             </handlers>
>         </subsystem>
> By process of elimination, I've found that removing the "enabled-cipher-suites" attribute makes the problem go away, so it appears this is the culprit.
> The value I'm using for this attribute has simply been copied from our jboss-web configuration, previously "cipher-suite".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 08:34:29 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 20 Jan 2014 08:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-408) version of
 org.codehaus.plexus:plexus-classworlds is missing
In-Reply-To: <JIRA.12529861.1390224814566@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529861.1390224814566@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529861.1390224814566.1905.1390224869219@jira02.app.mwc.hst.phx2.redhat.com>

Michael Biarnes Kiefer created DROOLS-408:
---------------------------------------------

             Summary: version of org.codehaus.plexus:plexus-classworlds is missing
                 Key: DROOLS-408
                 URL: https://issues.jboss.org/browse/DROOLS-408
             Project: Drools
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
         Environment: Fedora 19
            Reporter: Michael Biarnes Kiefer
            Assignee: Mario Fusco


We have transitive dependencies related to org.codehaus.plexus:plexus-classworlds. 
This module is not in the jboss-integration-platform-bom.

The are two version in the classpath: 1.2-alpha-10 and 2.4.

drools-jboss-integration
Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for org.codehaus.plexus:plexus-classworlds:1.2-alpha-10 paths to dependency are:
+-org.drools:drools-jboss-integration:6.1.0-SNAPSHOT
  +-org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-depchain:2.0.0-beta-3
    +-org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven-archive:2.0.0-beta-3
      +-org.codehaus.plexus:plexus-component-api:1.0-alpha-33
        +-org.codehaus.plexus:plexus-classworlds:1.2-alpha-10
and
+-org.drools:drools-jboss-integration:6.1.0-SNAPSHOT
  +-org.guvnor:guvnor-project-backend:6.1.0-20140114.214621-339
    +-org.kie:kie-ci:6.1.0-SNAPSHOT
      +-org.apache.maven:maven-core:3.0.5
        +-org.codehaus.plexus:plexus-classworlds:2.4
and
+-org.drools:drools-jboss-integration:6.1.0-SNAPSHOT
  +-org.guvnor:guvnor-project-backend:6.1.0-20140114.214621-339
    +-org.kie:kie-ci:6.1.0-SNAPSHOT
      +-org.sonatype.aether:aether-connector-wagon:1.13.1
        +-org.codehaus.plexus:plexus-classworlds:2.4
and
+-org.drools:drools-jboss-integration:6.1.0-SNAPSHOT
  +-org.guvnor:guvnor-project-backend:6.1.0-20140114.214621-339
    +-org.kie:kie-ci:6.1.0-SNAPSHOT
      +-org.apache.maven:maven-core:3.0.5
        +-org.sonatype.sisu:sisu-inject-plexus:2.2.3
          +-org.codehaus.plexus:plexus-classworlds:2.4
]

The actual version of org.codehaus.plexus is 3.0.7 in jboss-intergration-platform.bom.
The component plexus-classworlds does not exist for this version. Available until version 2.5.1. 

If this component (plexus-classwords) is very important for droolsjbpm-integration we should somehow add the groupID, atrifactID to jboss-inegration-platform.bom and the version <version.org.codehaus.plexus.plexus-classworlds>2.4</version.org.codehaus.plexus.plexus-classworlds>to the jboss-intergration-parent?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 08:42:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 20 Jan 2014 08:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2779) Update documentation for
 "connector" in mod_cluster subsystem
In-Reply-To: <JIRA.12529862.1390225286815@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529862.1390225286815@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529862.1390225286815.1930.1390225348982@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2779:
------------------------------------

             Summary: Update documentation for "connector" in mod_cluster subsystem
                 Key: WFLY-2779
                 URL: https://issues.jboss.org/browse/WFLY-2779
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 8.0.0.Final


https://community.jboss.org/message/852841?et=watches.email.thread#852841

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 08:52:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 20 Jan 2014 08:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1828) Wildfly High Availability
 Guide: Load-balancing (LB) and mod_cluster write up
In-Reply-To: <JIRA.12497989.1375720158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497989.1375720158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497989.1375720158000.1950.1390225948753@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937211#comment-12937211 ] 

Radoslav Husar commented on WFLY-1828:
--------------------------------------

noting to include alias configuration
https://community.jboss.org/message/852828?et=watches.email.thread#852828
                
> Wildfly High Availability Guide: Load-balancing (LB) and mod_cluster write up
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1828
>                 URL: https://issues.jboss.org/browse/WFLY-1828
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> https://docs.jboss.org/author/display/WFLY8/Load+Balancing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 09:00:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Jan 2014 09:00:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-385) KModules get added twice
In-Reply-To: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528350.1387663007000.1970.1390226429925@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-385.
--------------------------------

    Resolution: Done

    
> KModules get added twice
> ------------------------
>
>                 Key: DROOLS-385
>                 URL: https://issues.jboss.org/browse/DROOLS-385
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mario Fusco
>
> The class loader is returning duplicate entries, as it incorrectly implements:
>     @Override
>     protected Enumeration<URL> findResources(String name) throws IOException {
>         return getParent().getResources(name);
>     }
> Deleting this method resolves the problem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 09:10:28 2014
From: issues at jboss.org (Pedro Ruivo (JIRA))
Date: Mon, 20 Jan 2014 09:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1773)
 TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
In-Reply-To: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529686.1389959943000.1988.1390227028661@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937215#comment-12937215 ] 

Pedro Ruivo commented on JGRP-1773:
-----------------------------------

hmmm... I don't know why but when I saw the code last week, it looked like this array (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/UDP.java#L673) was created every time you read a datagram packet. I was wrong :)
                
> TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
> --------------------------------------------------------------------------
>
>                 Key: JGRP-1773
>                 URL: https://issues.jboss.org/browse/JGRP-1773
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When a single message is received, we pass it to the thread pool for parsing, passing a copy of the byte array to the MyHandler runnable.
> The parsing then creates a new Message and calls readFrom(). This method reads the headers and then creates a payload buffer of the size read from the input stream, then copies {{size}} bytes from the input stream to the mesage's payload.
> This is an unneeded copy; as we already have a copy of the byte array, we only need to *reference* the byte array from the message and set the offset and length, saving us one copy of the buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 09:24:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 09:24:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2446) invalid value for
 backup-group-name when it is undefined
In-Reply-To: <JIRA.12518117.1383736727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518117.1383736727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518117.1383736727000.2070.1390227869073@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937225#comment-12937225 ] 

RH Bugzilla Integration commented on WFLY-2446:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> changed the Status of [bug 1027384|https://bugzilla.redhat.com/show_bug.cgi?id=1027384] from NEW to POST
                
> invalid value for backup-group-name when it is undefined
> --------------------------------------------------------
>
>                 Key: WFLY-2446
>                 URL: https://issues.jboss.org/browse/WFLY-2446
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> In the messaging configuration, the backup-group-node modelNode is passed directly to the HornetQ configuration without checking whether it is defined.
> If it is not undefined, the hornetq configuration will use the "undefined" string as the backup group name instead of returning 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 issues at jboss.org  Mon Jan 20 09:30:29 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 20 Jan 2014 09:30:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" DMR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.2088.1390228229446@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reassigned WFLY-91:
-------------------------------------

    Assignee: Tomaz Cerar  (was: Alexey Loubyansky)


IMO, this issue can be closed as long as there is a known reliable way to perform reload (from tests) and then continue the communication with the reloaded controller.

I was assigned this issue because I spent time on reload command in the cli which was supposed to be reliable in that sense. I could make it much more robust than the corresponding operation but still couldn't get it to work 100% of the time (based on stress testing I've done at the time).

This issue is not about the CLI, although, the nature of the problem is practically the same.
Tomaz, you seem to be more up-to-date on this, could you please point to a test which can be used as an example for others and so the issue can be closed? Thanks.
                
> Impossible to use "reload" DMR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 09:42:29 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Mon, 20 Jan 2014 09:42:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" DMR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.2131.1390228949297@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937233#comment-12937233 ] 

Karel Piwko commented on WFLY-91:
---------------------------------

[~aloubyansky] that's my understanding as well. Test is located here, with reference to reload operation: https://github.com/baranowb/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/bootstrap/CustomBootstrapContextTestCase.java#L102

So, I you said, I believe this issue can be closed as resolved.
                
> Impossible to use "reload" DMR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 09:44:29 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 20 Jan 2014 09:44:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" DMR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.2147.1390229069166@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937235#comment-12937235 ] 

Alexey Loubyansky commented on WFLY-91:
---------------------------------------

I'd ask Vladimir (the reporter) to confirm this is actually fixed.
                
> Impossible to use "reload" DMR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	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.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:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	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.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: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 issues at jboss.org  Mon Jan 20 09:48:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 09:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2499) JMSBridge FailureHandler does
 not load from specified module
In-Reply-To: <JIRA.12524963.1384336124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524963.1384336124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524963.1384336124000.2154.1390229308622@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937237#comment-12937237 ] 

RH Bugzilla Integration commented on WFLY-2499:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> changed the Status of [bug 1029836|https://bugzilla.redhat.com/show_bug.cgi?id=1029836] from NEW to POST
                
> JMSBridge FailureHandler does not load from specified module
> ------------------------------------------------------------
>
>                 Key: WFLY-2499
>                 URL: https://issues.jboss.org/browse/WFLY-2499
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> If an error occurs and the JMS bridge tries to reconnect to the JMS provider to look up the JMS resources from its FailureHandler, it fails with the exception:
> Stack trace:
> {noformat}
> 10:37:02,546 INFO  [org.hornetq.jms.server] (pool-3-thread-3) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 1,000 ms
> 10:37:03,547 WARN  [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.apache.qpid.jndi.PropertiesFileInitialContextFactory from classloader ModuleClassLoader for Module "org.hornetq:main" from local module loader @ac44b88 (finder: local module finder @5d3ad33d (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
>     at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:64)
>     at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681) [rt.jar:1.6.0_24]
>     at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) [rt.jar:1.6.0_24]
>     at javax.naming.InitialContext.init(InitialContext.java:240) [rt.jar:1.6.0_24]
>     at javax.naming.InitialContext.<init>(InitialContext.java:214) [rt.jar:1.6.0_24]
>     at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1222) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1460) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2000(JMSBridgeImpl.java:83) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2049) [hornetq-jms-server.jar:]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
>     at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
> {noformat}
> The issue is that the ExecutorService executing the FailureHandler is created when the JMSBridge is instantiated and will not use the ClassLoader from the specified module that gives access to the JMS provider's classes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 10:24:28 2014
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 20 Jan 2014 10:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-409) Transitive dependencies for
 org.apache.lucene:lucene-core
In-Reply-To: <JIRA.12529884.1390231375154@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529884.1390231375154@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529884.1390231375154.2243.1390231468551@jira02.app.mwc.hst.phx2.redhat.com>

Michael Biarnes Kiefer created DROOLS-409:
---------------------------------------------

             Summary: Transitive dependencies for org.apache.lucene:lucene-core
                 Key: DROOLS-409
                 URL: https://issues.jboss.org/browse/DROOLS-409
             Project: Drools
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
         Environment: Fedora 19
            Reporter: Michael Biarnes Kiefer
            Assignee: Alexandre Porcelli


In jboss-integration-platfor-parent we have defined the version <version.org.apache.lucene>3.6.2</version.org.apache.lucene>. The component of org.apache.lucene:lucene-core has this version, declared in the jboss integration platform-bom.
      <dependency>
        <groupId>org.apache.lucene</groupId>
        <artifactId>lucene-core</artifactId>
        <version>${version.org.apache.lucene}</version>
      </dependency>

The module drools-wb-jcr2vfs-migration-core has transitive dependencies to lucene-core 2.4.1. and 4.0.0.

Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for org.apache.lucene:lucene-core:2.4.1 paths to dependency are:
+-org.drools:drools-wb-jcr2vfs-migration-core:6.1.0-SNAPSHOT
  +-org.apache.lucene:lucene-core:2.4.1
and
+-org.drools:drools-wb-jcr2vfs-migration-core:6.1.0-SNAPSHOT
  +-org.drools:guvnor-repository:5.6.0.CR1
    +-org.drools:guvnor-repository-connector-jackrabbit:5.6.0.CR1
      +-org.apache.jackrabbit:jackrabbit-core:2.2.8
        +-org.apache.lucene:lucene-core:4.0.0

At least we have three different versions of lucene-core in our modules.
2.4.1, 3.6.2 and 4.0.0.

How can we 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 issues at jboss.org  Mon Jan 20 10:44:28 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 20 Jan 2014 10:44:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2726) Update JSF based on Mojarra
	2.2.5 final
In-Reply-To: <JIRA.12528881.1389202100000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528881.1389202100000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528881.1389202100000.2267.1390232668865@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-2726:
-----------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5729  (was: https://issues.jboss.org/browse/WFLY-2726)

    
> Update JSF based on Mojarra 2.2.5 final
> ---------------------------------------
>
>                 Key: WFLY-2726
>                 URL: https://issues.jboss.org/browse/WFLY-2726
>             Project: WildFly
>          Issue Type: Library Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Leandro Kersting de Freitas
>            Assignee: Farah Juma
>             Fix For: 8.0.0.Final
>
>
> Update JSF based on Mojarra 2.2.5 final.
> https://javaserverfaces.java.net/nonav/2.2/releasenotes.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 issues at jboss.org  Mon Jan 20 11:02:28 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 20 Jan 2014 11:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2780) Decoration of Servlet
	AsyncListener fails
In-Reply-To: <JIRA.12529886.1390233731075@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529886.1390233731075@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529886.1390233731075.2330.1390233748795@jira02.app.mwc.hst.phx2.redhat.com>

Tomas Remes created WFLY-2780:
---------------------------------

             Summary: Decoration of Servlet AsyncListener fails
                 Key: WFLY-2780
                 URL: https://issues.jboss.org/browse/WFLY-2780
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.CR1
            Reporter: Tomas Remes
            Assignee: Stuart Douglas


I am not sure, whether this should work (maybe it should, when interceptor works) or not, but I think it shouldn't throw this exception:
{noformat}
16:08:55,010 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."asyncServletExample.war".component."org.jboss.asyncServletExamples.MyListenerDecorator".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."asyncServletExample.war".component."org.jboss.asyncServletExamples.MyListenerDecorator".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000038: Cannot place @Delegate at an injection point which is not on a Decorator: InjectionTarget for [BackedAnnotatedType] public abstract @Decorator class org.jboss.asyncServletExamples.MyListenerDecorator
	at org.jboss.weld.injection.producer.AbstractProducer.checkDelegateInjectionPoints(AbstractProducer.java:31)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
	at org.jboss.as.weld.injection.InterceptedNonContextualComponentInjectionTarget.<init>(InterceptedNonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.InjectionTargets.createInjectionTarget(InjectionTargets.java:62)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:118)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	... 3 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 issues at jboss.org  Mon Jan 20 11:06:28 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Mon, 20 Jan 2014 11:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2780) Decoration of Servlet
	AsyncListener fails
In-Reply-To: <JIRA.12529886.1390233731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529886.1390233731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529886.1390233731000.2333.1390233988537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated WFLY-2780:
------------------------------

    Attachment: asyncSevlet.zip


Reproducer - just extract and run "mvn clean test"
                
> Decoration of Servlet AsyncListener fails
> -----------------------------------------
>
>                 Key: WFLY-2780
>                 URL: https://issues.jboss.org/browse/WFLY-2780
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Stuart Douglas
>         Attachments: asyncSevlet.zip
>
>
> I am not sure, whether this should work (maybe it should, when interceptor works) or not, but I think it shouldn't throw this exception:
> {noformat}
> 16:08:55,010 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."asyncServletExample.war".component."org.jboss.asyncServletExamples.MyListenerDecorator".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."asyncServletExample.war".component."org.jboss.asyncServletExamples.MyListenerDecorator".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000038: Cannot place @Delegate at an injection point which is not on a Decorator: InjectionTarget for [BackedAnnotatedType] public abstract @Decorator class org.jboss.asyncServletExamples.MyListenerDecorator
> 	at org.jboss.weld.injection.producer.AbstractProducer.checkDelegateInjectionPoints(AbstractProducer.java:31)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
> 	at org.jboss.as.weld.injection.InterceptedNonContextualComponentInjectionTarget.<init>(InterceptedNonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.InjectionTargets.createInjectionTarget(InjectionTargets.java:62)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:118)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	... 3 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 issues at jboss.org  Mon Jan 20 11:22:28 2014
From: issues at jboss.org (Tristan Tarrant (JIRA))
Date: Mon, 20 Jan 2014 11:22:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1809) The security subsystem
 plugins use deprecated Infinispan API
In-Reply-To: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497821.1375428478000.2381.1390234948842@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tristan Tarrant updated WFLY-1809:
----------------------------------

    Assignee: Paul Ferraro  (was: Tristan Tarrant)

    
> The security subsystem plugins use deprecated Infinispan API
> ------------------------------------------------------------
>
>                 Key: WFLY-1809
>                 URL: https://issues.jboss.org/browse/WFLY-1809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: NadirX
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> org.jboss.as.security.plugins.JNDIBasedSecurityManagement uses a deprecated way of configuring an Infinispan cache which must 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 issues at jboss.org  Mon Jan 20 11:22:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 20 Jan 2014 11:22:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.2384.1390234948947@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937272#comment-12937272 ] 

Jozef Hartinger commented on WFLY-2689:
---------------------------------------

I fixed WFLY-2761 which I think is the root cause of this issue. Can you verify that your testcase works with https://github.com/jharting/wildfly/tree/WFLY-2761?
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Jozef Hartinger
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 12:10:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 20 Jan 2014 12:10:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.2508.1390237829096@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937284#comment-12937284 ] 

David Lloyd commented on WFLY-2778:
-----------------------------------

Those stack traces look a bit goofy.  Are you sure you used jstack from the same JVM that was running the hung process?
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 13:52:28 2014
From: issues at jboss.org (Alexandre Porcelli (JIRA))
Date: Mon, 20 Jan 2014 13:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-409) Transitive dependencies for
 org.apache.lucene:lucene-core
In-Reply-To: <JIRA.12529884.1390231375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529884.1390231375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529884.1390231375000.2584.1390243948696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937300#comment-12937300 ] 

Alexandre Porcelli commented on DROOLS-409:
-------------------------------------------

A general overview of this situation:

jboss-integration-platfor-parent:3.6.2

 We don't have control over integration bom - and we have a situation where one component of the bom (modeshape) needs to use 3.6.2 (in fact what makes modeshape needs it is hibernate-search that uses 3.6.2)

kie-parent-with-dependencies:4.0

 Kie uses UberFire for tooling and has no relation to Modeshape - so we had to overwrite integration bom with lucene 4.0

drools-wb-jcr2vfs-migration-core:mixed versions

 The issue here comes from the need to update an old JCR repository to new git based one. The new repository is a UberFire repository, that uses lucene version 4 and old JCR repository is a jackrabbit repository - and probably jackrabbit has lucene 2.4.1 dependency.

 All this to say that would be hard to fix this issue as we need port old repositorty to new one.
                
> Transitive dependencies for org.apache.lucene:lucene-core
> ---------------------------------------------------------
>
>                 Key: DROOLS-409
>                 URL: https://issues.jboss.org/browse/DROOLS-409
>             Project: Drools
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: Fedora 19
>            Reporter: Michael Biarnes Kiefer
>            Assignee: Alexandre Porcelli
>
> In jboss-integration-platfor-parent we have defined the version <version.org.apache.lucene>3.6.2</version.org.apache.lucene>. The component of org.apache.lucene:lucene-core has this version, declared in the jboss integration platform-bom.
>       <dependency>
>         <groupId>org.apache.lucene</groupId>
>         <artifactId>lucene-core</artifactId>
>         <version>${version.org.apache.lucene}</version>
>       </dependency>
> The module drools-wb-jcr2vfs-migration-core has transitive dependencies to lucene-core 2.4.1. and 4.0.0.
> Failed while enforcing RequireUpperBoundDeps. The error(s) are [
> Require upper bound dependencies error for org.apache.lucene:lucene-core:2.4.1 paths to dependency are:
> +-org.drools:drools-wb-jcr2vfs-migration-core:6.1.0-SNAPSHOT
>   +-org.apache.lucene:lucene-core:2.4.1
> and
> +-org.drools:drools-wb-jcr2vfs-migration-core:6.1.0-SNAPSHOT
>   +-org.drools:guvnor-repository:5.6.0.CR1
>     +-org.drools:guvnor-repository-connector-jackrabbit:5.6.0.CR1
>       +-org.apache.jackrabbit:jackrabbit-core:2.2.8
>         +-org.apache.lucene:lucene-core:4.0.0
> At least we have three different versions of lucene-core in our modules.
> 2.4.1, 3.6.2 and 4.0.0.
> How can we 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 issues at jboss.org  Mon Jan 20 13:52:28 2014
From: issues at jboss.org (Alexandre Porcelli (JIRA))
Date: Mon, 20 Jan 2014 13:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-409) Transitive dependencies for
 org.apache.lucene:lucene-core
In-Reply-To: <JIRA.12529884.1390231375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529884.1390231375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529884.1390231375000.2588.1390243948929@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexandre Porcelli resolved DROOLS-409.
---------------------------------------

    Resolution: Won't Fix

    
> Transitive dependencies for org.apache.lucene:lucene-core
> ---------------------------------------------------------
>
>                 Key: DROOLS-409
>                 URL: https://issues.jboss.org/browse/DROOLS-409
>             Project: Drools
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: Fedora 19
>            Reporter: Michael Biarnes Kiefer
>            Assignee: Alexandre Porcelli
>
> In jboss-integration-platfor-parent we have defined the version <version.org.apache.lucene>3.6.2</version.org.apache.lucene>. The component of org.apache.lucene:lucene-core has this version, declared in the jboss integration platform-bom.
>       <dependency>
>         <groupId>org.apache.lucene</groupId>
>         <artifactId>lucene-core</artifactId>
>         <version>${version.org.apache.lucene}</version>
>       </dependency>
> The module drools-wb-jcr2vfs-migration-core has transitive dependencies to lucene-core 2.4.1. and 4.0.0.
> Failed while enforcing RequireUpperBoundDeps. The error(s) are [
> Require upper bound dependencies error for org.apache.lucene:lucene-core:2.4.1 paths to dependency are:
> +-org.drools:drools-wb-jcr2vfs-migration-core:6.1.0-SNAPSHOT
>   +-org.apache.lucene:lucene-core:2.4.1
> and
> +-org.drools:drools-wb-jcr2vfs-migration-core:6.1.0-SNAPSHOT
>   +-org.drools:guvnor-repository:5.6.0.CR1
>     +-org.drools:guvnor-repository-connector-jackrabbit:5.6.0.CR1
>       +-org.apache.jackrabbit:jackrabbit-core:2.2.8
>         +-org.apache.lucene:lucene-core:4.0.0
> At least we have three different versions of lucene-core in our modules.
> 2.4.1, 3.6.2 and 4.0.0.
> How can we 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 issues at jboss.org  Mon Jan 20 14:12:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Jan 2014 14:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2781) Incorrect description of
 HostControllerEnvironment host-controller-address and host-controller-port
In-Reply-To: <JIRA.12529905.1390245096353@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529905.1390245096353@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529905.1390245096353.2596.1390245148836@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2781:
--------------------------------------

             Summary: Incorrect description of HostControllerEnvironment host-controller-address and host-controller-port
                 Key: WFLY-2781
                 URL: https://issues.jboss.org/browse/WFLY-2781
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 8.0.0.Final


The javadoc and management API text description implies that these attributes relate to communication with servers. They don't. They relate to the client-side of the HC/PC communication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 14:24:28 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 20 Jan 2014 14:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829615@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829615@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829615.2600.1390245868902@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2782:
--------------------------------

             Summary: Testsuite leaks remoting endpoints by not closing JMXConnector
                 Key: WFLY-2782
                 URL: https://issues.jboss.org/browse/WFLY-2782
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.CR1
            Reporter: Kabir Khan
            Assignee: Ondrej Zizka
             Fix For: 8.0.0.Final


Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 14:24:29 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 20 Jan 2014 14:24:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.2603.1390245869102@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2782:
--------------------------------

    Assignee: Kabir Khan  (was: Ondrej Zizka)

    
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 14:30:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 14:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.2606.1390246228627@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937302#comment-12937302 ] 

RH Bugzilla Integration commented on WFLY-2021:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1022265|https://bugzilla.redhat.com/show_bug.cgi?id=1022265] from NEW to MODIFIED
                
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> 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 issues at jboss.org  Mon Jan 20 14:58:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Jan 2014 14:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2427) Launcher API
In-Reply-To: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509240.1383251005000.2626.1390247908812@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937306#comment-12937306 ] 

Brian Stansberry commented on WFLY-2427:
----------------------------------------

This shouldn't be calling standalone.sh or standlone.bat. It should use ProcessBuilder to do internally what the scripts do, a la what org.jboss.as.arquillian.container.managed.ManagedDeployableContainer does. ManagedDeployableContainer and other code like that in the current WF codebase would then stop doing all this stuff manually and instead would use this launcher API.
                
> Launcher API
> ------------
>
>                 Key: WFLY-2427
>                 URL: https://issues.jboss.org/browse/WFLY-2427
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. 
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. 
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -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 "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.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 issues at jboss.org  Mon Jan 20 15:28:28 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 20 Jan 2014 15:28:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.2647.1390249708699@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937310#comment-12937310 ] 

Ot?vio Garcia commented on WFLY-2690:
-------------------------------------

Any news about this issues?
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 20 15:30:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 20 Jan 2014 15:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.2653.1390249828750@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937312#comment-12937312 ] 

Jozef Hartinger commented on WFLY-2690:
---------------------------------------

It was resolved. You can use a nightly build or wait for Final.
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 20 15:34:28 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 20 Jan 2014 15:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.2668.1390250068803@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937316#comment-12937316 ] 

Ot?vio Garcia commented on WFLY-2690:
-------------------------------------

 Jozef, thank you. I can compile from github. It's on weld repository?
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 20 15:36:28 2014
From: issues at jboss.org (=?UTF-8?Q?Ot=C3=A1vio_Garcia_=28JIRA=29?=)
Date: Mon, 20 Jan 2014 15:36:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2690) JSP/JSPX tags don't work with
	Wildfly CR1
In-Reply-To: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528434.1388105745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528434.1388105745000.2672.1390250188650@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937317#comment-12937317 ] 

Ot?vio Garcia commented on WFLY-2690:
-------------------------------------

Oh, now I see the commit. Thank you.
                
> JSP/JSPX tags don't work with Wildfly CR1
> -----------------------------------------
>
>                 Key: WFLY-2690
>                 URL: https://issues.jboss.org/browse/WFLY-2690
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: OpenJDK Runtime Environment (fedora-2.4.3.0.fc18-x86_64 u45-b15)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Ot?vio Garcia
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> My app works fine on JBoss AS 7.1. When I migrate to Wildfly 8.0.0 CR1, my JSP tags don't work as expected. My project is a EAR with WAR module.
> When app starts, in the 1st access to page A, tag file is compiled and the page are rendered fine. But when I access another page (B in example), I got this error: org.apache.jasper.JasperException: java.lang.ClassCastException: org.apache.jsp.tag.web.default_tagx cannot be cast to org.apache.jsp.tag.web.default_tagx
> If I restart Wildfly and try to access page B, works fine. But when I access page A, I got the same error.
> My default.tagx is bellow:
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml" version="2.2">
>     <jsp:output doctype-root-element="HTML" doctype-system="about:legacy-compat" omit-xml-declaration="yes" />
>     some code
>     <jsp:doBody />
>     more code
> </jsp:root>
> And the pages are somethink like this:
> <tags:default xmlns:tags="urn:jsptagdir:/WEB-INF/tags" xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:html="http://www.w3.org/1999/xhtml">
>     <jsp:output omit-xml-declaration="yes" />
>     my code here
> </tags:default>
> I was created a new empty project with two pages and one tagfile. The error don't occurs. But when I add CDI capabilities, the error occurs. There are something in CDI that confuses Jastow?
> As discussed here: https://community.jboss.org/message/850730

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 20 15:38:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 15:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.2675.1390250308506@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2782:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1055740

    
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 15:54:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Mon, 20 Jan 2014 15:54:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5306)
 DomainControllerMigrationTestCase.testDCFailover intermittently fails
In-Reply-To: <JIRA.12471817.1344078762000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471817.1344078762000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471817.1344078762000.2703.1390251269004@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937318#comment-12937318 ] 

Aleksandar Kostadinov commented on AS7-5306:
--------------------------------------------

FYI it looks like JBQA-8866 has the same root cause. See there for explanation.
                
> DomainControllerMigrationTestCase.testDCFailover intermittently fails
> ---------------------------------------------------------------------
>
>                 Key: AS7-5306
>                 URL: https://issues.jboss.org/browse/AS7-5306
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 7.1.3.Final (EAP)
>            Reporter: Kabir Khan
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> Stacktrace
> {code}
> junit.framework.AssertionFailedError
> 	at junit.framework.Assert.fail(Assert.java:48)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertTrue(Assert.java:27)
> 	at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:209)
> 	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:45)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 	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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Standard Output
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/domain-configs/domain-standard.xml
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/host-configs/host-failover1.xml
> 04:02:08,268 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> 04:02:08,383 INFO  [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 04:02:08,866 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Host Controller] 04:02:09,068 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Host Controller] 04:02:09,139 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:09,998 INFO  [org.xnio] (MSC service thread 1-3) XNIO Version 3.0.5.GA
> [Host Controller] 04:02:10,006 INFO  [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.0.5.GA
> [Host Controller] 04:02:10,016 INFO  [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:10,071 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (9990) securePort (-1)
> [Host Controller] 04:02:10,236 INFO  [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on [::1]:9999
> [Host Controller] 04:02:10,869 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,432 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:11,493 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,504 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:11,506 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,507 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,509 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,510 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,511 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,513 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:12,204 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server failover-one
> 04:02:12,264 INFO  [org.jboss.as.process.Server:failover-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:failover-one'
> [Host Controller] 04:02:12,364 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://::1:9990/management
> [Host Controller] 04:02:12,366 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://::1:9990
> [Host Controller] 04:02:12,367 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 3882ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Server:failover-one] 04:02:13,073 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Server:failover-one] 04:02:13,405 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Server:failover-one] 04:02:13,505 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Server:failover-one] 04:02:13,625 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.5.GA
> [Server:failover-one] 04:02:13,637 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.5.GA
> [Server:failover-one] 04:02:13,664 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:15,369 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-one] registered using connection [Channel ID 46504c6e (inbound) of Remoting connection 0b412c18 to /0:0:0:0:0:0:0:1:52549]
> [Server:failover-one] 04:02:15,387 INFO  [org.jboss.as.logging] (MSC service thread 1-1) JBAS011502: Removing bootstrap log handlers
> [Server:failover-one] 04:02:15,402 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 29) JBAS015537: Activating WebServices Extension
> [Server:failover-one] 04:02:15,413 INFO  [org.jboss.as.modcluster] (ServerService Thread Pool -- 28) JBAS011704: Mod_cluster uses default load balancer provider
> [Server:failover-one] 04:02:15,459 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [Server:failover-one] 04:02:15,551 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> [Server:failover-one] 04:02:15,557 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) JBAS010260: Activating JGroups subsystem.
> [Server:failover-one] 04:02:15,559 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [Server:failover-one] 04:02:15,649 INFO  [org.jboss.as.security] (MSC service thread 1-6) JBAS013170: Current PicketBox version=4.0.9.Final
> [Server:failover-one] 04:02:15,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 47) JBAS010280: Activating Infinispan subsystem.
> [Server:failover-one] 04:02:15,689 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [Server:failover-one] 04:02:15,907 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> [Server:failover-one] 04:02:15,948 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [Server:failover-one] 04:02:16,037 INFO  [org.jboss.jaxr] (MSC service thread 1-2) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
> [Server:failover-one] 04:02:16,150 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-5) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> [Server:failover-one] 04:02:16,870 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032010: JBossTS Recovery Service (tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-one] 04:02:16,975 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012324: Start RecoveryActivators
> [Server:failover-one] 04:02:17,040 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-one] 04:02:17,052 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-one] 04:02:17,256 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-localhost/0:0:0:0:0:0:0:1%1:8009
> [Server:failover-one] 04:02:17,288 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http-localhost/0:0:0:0:0:0:0:1%1:8080
> [Server:failover-one] 04:02:17,272 INFO  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012296: ExpiredEntryMonitor running at Sat, 4 Aug 2012 04:02:17
> [Server:failover-one] 04:02:17,472 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messagingjournal,bindingsDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messagingbindings,largeMessagesDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messaginglargemessages,pagingDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messagingpaging)
> [Server:failover-one] 04:02:17,483 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.1.Final
> [Server:failover-one] 04:02:17,523 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 54) Listening to proxy advertisements on 224.0.1.105:23,364
> [Server:failover-one] 04:02:17,685 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c 0:0:0:0:0:0:0:1%1:5445 for CORE protocol
> [Server:failover-one] 04:02:17,706 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c 0:0:0:0:0:0:0:1%1:5455 for CORE protocol
> [Server:failover-one] 04:02:17,721 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012343: RecoveryManagerImple is ready. Socket listener is turned off.
> [Server:failover-one] 04:02:17,725 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) Server is now live
> [Server:failover-one] 04:02:17,730 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032013: Starting transaction recovery manager
> [Server:failover-one] 04:02:17,730 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [b585cf0b-de0a-11e1-839e-7305fde0f34e]) started
> [Server:failover-one] 04:02:17,938 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-2) ARJUNA032017: JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-one] 04:02:17,955 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 54) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> [Server:failover-one] 04:02:17,962 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 57) trying to deploy queue jms.topic.testTopic
> [Server:failover-one] 04:02:18,164 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [Server:failover-one] 04:02:18,210 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-5) JBAS010406: Registered connection factory java:/JmsXA
> [Server:failover-one] 04:02:18,203 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 57) JBAS011601: Bound messaging object to jndi name java:/topic/test
> [Server:failover-one] 04:02:18,226 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 56) trying to deploy queue jms.queue.testQueue
> [Server:failover-one] 04:02:18,259 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 56) JBAS011601: Bound messaging object to jndi name java:/queue/test
> [Server:failover-one] 04:02:18,261 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 55) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
> [Server:failover-one] 04:02:18,302 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-5) HornetQ resource adaptor started
> [Server:failover-one] 04:02:18,303 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-5) IJ020002: Deployed: file://RaActivatorhornetq-ra
> [Server:failover-one] 04:02:18,309 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> [Server:failover-one] 04:02:18,764 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> [Server:failover-one] JBAS014775:    New missing/unsatisfied dependencies:
> [Server:failover-one]       service jboss.server.controller.management.security_realm.ApplicationRealm (missing) dependents: [service jboss.remoting.authentication_provider.remoting-connector] 
> [Server:failover-one] 
> [Server:failover-one] 04:02:18,779 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 6253ms - Started 138 of 221 services (4 services failed or missing dependencies, 78 services are passive or on-demand)
> [Host Controller] 04:02:18,792 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-one
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/domain-configs/domain-standard.xml
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/host-configs/host-failover2.xml
> 04:02:19,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> 04:02:19,835 INFO  [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 04:02:20,446 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Host Controller] 04:02:20,653 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Host Controller] 04:02:20,803 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:22,015 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (9980) securePort (-1)
> [Host Controller] 04:02:22,015 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.5.GA
> [Host Controller] 04:02:22,059 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.5.GA
> [Host Controller] 04:02:22,102 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:22,319 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on [fccc::2]:9989
> [Host Controller] 04:02:24,415 INFO  [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "failover2", JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes"
> [Host Controller] 04:02:24,662 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server failover-two
> 04:02:24,724 INFO  [org.jboss.as.process.Server:failover-two.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:failover-two'
> [Host Controller] 04:02:24,734 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:9980/management
> [Host Controller] 04:02:24,736 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015954: Admin console is not enabled
> [Host Controller] 04:02:24,737 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 4798ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Server:failover-two] 04:02:25,479 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Server:failover-two] 04:02:25,808 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Server:failover-two] 04:02:26,014 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Server:failover-two] 04:02:26,324 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.5.GA
> [Server:failover-two] 04:02:26,355 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.5.GA
> [Server:failover-two] 04:02:26,386 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:27,913 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-two] registered using connection [Channel ID 28a61589 (inbound) of Remoting connection 21044daf to /fccc:0:0:0:0:0:0:2:54201]
> [Server:failover-two] 04:02:27,971 INFO  [org.jboss.as.logging] (MSC service thread 1-5) JBAS011502: Removing bootstrap log handlers
> [Server:failover-two] 04:02:27,986 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 29) JBAS015537: Activating WebServices Extension
> [Server:failover-two] 04:02:27,990 INFO  [org.jboss.as.modcluster] (ServerService Thread Pool -- 28) JBAS011704: Mod_cluster uses default load balancer provider
> [Server:failover-two] 04:02:28,060 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [Server:failover-two] 04:02:28,066 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [Server:failover-two] 04:02:28,101 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> [Server:failover-two] 04:02:28,125 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) JBAS010260: Activating JGroups subsystem.
> [Server:failover-two] 04:02:28,142 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-3) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [Server:failover-two] 04:02:28,148 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 47) JBAS010280: Activating Infinispan subsystem.
> [Server:failover-two] 04:02:28,161 INFO  [org.jboss.as.security] (MSC service thread 1-2) JBAS013170: Current PicketBox version=4.0.9.Final
> [Server:failover-two] 04:02:28,275 INFO  [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> [Server:failover-two] 04:02:28,329 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [Server:failover-two] 04:02:28,452 INFO  [org.jboss.jaxr] (MSC service thread 1-4) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
> [Server:failover-two] 04:02:28,567 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> [Server:failover-two] 04:02:29,090 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http-/fccc:0:0:0:0:0:0:2%1:8430
> [Server:failover-two] 04:02:29,114 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-two] 04:02:29,120 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-two] 04:02:29,105 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-6) Starting Coyote AJP/1.3 on ajp-/fccc:0:0:0:0:0:0:2%1:8359
> [Server:failover-two] 04:02:29,261 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032010: JBossTS Recovery Service (tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-two] 04:02:29,317 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messagingjournal,bindingsDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messagingbindings,largeMessagesDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messaginglargemessages,pagingDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messagingpaging)
> [Server:failover-two] 04:02:29,318 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012324: Start RecoveryActivators
> [Server:failover-two] 04:02:29,380 INFO  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012296: ExpiredEntryMonitor running at Sat, 4 Aug 2012 04:02:29
> [Server:failover-two] 04:02:29,512 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.1.Final
> [Server:failover-two] 04:02:29,587 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012343: RecoveryManagerImple is ready. Socket listener is turned off.
> [Server:failover-two] 04:02:29,589 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032013: Starting transaction recovery manager
> [Server:failover-two] 04:02:29,607 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 54) Listening to proxy advertisements on 224.0.1.105:23,364
> [Server:failover-two] 04:02:29,821 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-5) ARJUNA032017: JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-two] 04:02:29,941 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:5795 for CORE protocol
> [Server:failover-two] 04:02:29,955 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:5805 for CORE protocol
> [Server:failover-two] 04:02:29,957 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) Server is now live
> [Server:failover-two] 04:02:29,957 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [bc931309-de0a-11e1-bf84-3397a847e4d3]) started
> [Server:failover-two] 04:02:29,977 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [Server:failover-two] 04:02:30,057 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 54) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
> [Server:failover-two] 04:02:30,060 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 57) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> [Server:failover-two] 04:02:30,062 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 56) trying to deploy queue jms.queue.testQueue
> [Server:failover-two] 04:02:30,091 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-6) JBAS010406: Registered connection factory java:/JmsXA
> [Server:failover-two] 04:02:30,171 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-6) HornetQ resource adaptor started
> [Server:failover-two] 04:02:30,172 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-6) IJ020002: Deployed: file://RaActivatorhornetq-ra
> [Server:failover-two] 04:02:30,176 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> [Server:failover-two] 04:02:30,185 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 56) JBAS011601: Bound messaging object to jndi name java:/queue/test
> [Server:failover-two] 04:02:30,187 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 55) trying to deploy queue jms.topic.testTopic
> [Server:failover-two] 04:02:30,241 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 55) JBAS011601: Bound messaging object to jndi name java:/topic/test
> [Server:failover-two] 04:02:30,719 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> [Server:failover-two] JBAS014775:    New missing/unsatisfied dependencies:
> [Server:failover-two]       service jboss.server.controller.management.security_realm.ApplicationRealm (missing) dependents: [service jboss.remoting.authentication_provider.remoting-connector] 
> [Server:failover-two] 
> [Server:failover-two] 04:02:30,808 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 5937ms - Started 138 of 221 services (4 services failed or missing dependencies, 78 services are passive or on-demand)
> [Host Controller] 04:02:30,820 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-two
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/domain-configs/domain-standard.xml
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/host-configs/host-failover3.xml
> 04:02:31,516 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> 04:02:31,632 INFO  [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 04:02:32,148 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Host Controller] 04:02:32,330 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Host Controller] 04:02:32,399 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:32,904 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (19990) securePort (-1)
> [Host Controller] 04:02:32,906 INFO  [org.xnio] (MSC service thread 1-6) XNIO Version 3.0.5.GA
> [Host Controller] 04:02:32,933 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.0.5.GA
> [Host Controller] 04:02:32,943 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:33,109 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on [fccc::2]:19999
> [Host Controller] 04:02:36,061 INFO  [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "failover3", JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes"
> [Host Controller] 04:02:36,206 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server failover-three
> 04:02:36,263 INFO  [org.jboss.as.process.Server:failover-three.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:failover-three'
> [Host Controller] 04:02:36,274 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:19990/management
> [Host Controller] 04:02:36,277 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015954: Admin console is not enabled
> [Host Controller] 04:02:36,277 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 4533ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Server:failover-three] 04:02:36,910 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Server:failover-three] 04:02:37,319 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Server:failover-three] 04:02:37,531 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Server:failover-three] 04:02:37,828 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.5.GA
> [Server:failover-three] 04:02:37,848 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.5.GA
> [Server:failover-three] 04:02:37,858 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:39,255 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-three] registered using connection [Channel ID 354ca75c (inbound) of Remoting connection 5fb57890 to /fccc:0:0:0:0:0:0:2:35193]
> [Server:failover-three] 04:02:39,425 INFO  [org.jboss.as.logging] (MSC service thread 1-5) JBAS011502: Removing bootstrap log handlers
> [Server:failover-three] 04:02:39,445 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 29) JBAS015537: Activating WebServices Extension
> [Server:failover-three] 04:02:39,491 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [Server:failover-three] 04:02:39,494 INFO  [org.jboss.as.modcluster] (ServerService Thread Pool -- 28) JBAS011704: Mod_cluster uses default load balancer provider
> [Server:failover-three] 04:02:39,498 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [Server:failover-three] 04:02:39,512 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) JBAS010260: Activating JGroups subsystem.
> [Server:failover-three] 04:02:39,525 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> [Server:failover-three] 04:02:39,543 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 47) JBAS010280: Activating Infinispan subsystem.
> [Server:failover-three] 04:02:39,651 INFO  [org.jboss.as.security] (MSC service thread 1-6) JBAS013170: Current PicketBox version=4.0.9.Final
> [Server:failover-three] 04:02:39,824 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [Server:failover-three] 04:02:39,981 INFO  [org.jboss.as.naming] (MSC service thread 1-6) JBAS011802: Starting Naming Service
> [Server:failover-three] 04:02:40,012 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [Server:failover-three] 04:02:40,033 INFO  [org.jboss.jaxr] (MSC service thread 1-4) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
> [Server:failover-three] 04:02:40,127 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-2) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> [Server:failover-three] 04:02:40,332 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-/fccc:0:0:0:0:0:0:2%1:8559
> [Server:failover-three] 04:02:40,372 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/fccc:0:0:0:0:0:0:2%1:8630
> [Server:failover-three] 04:02:40,430 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032010: JBossTS Recovery Service (tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-three] 04:02:40,490 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.1.Final
> [Server:failover-three] 04:02:40,614 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-5) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messagingjournal,bindingsDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messagingbindings,largeMessagesDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messaginglargemessages,pagingDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messagingpaging)
> [Server:failover-three] 04:02:40,625 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-3) ARJUNA012324: Start RecoveryActivators
> [Server:failover-three] 04:02:40,626 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-three] 04:02:40,637 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 54) Listening to proxy advertisements on 224.0.1.105:23,364
> [Server:failover-three] 04:02:40,659 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-three] 04:02:40,707 INFO  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012296: ExpiredEntryMonitor running at Sat, 4 Aug 2012 04:02:40
> [Server:failover-three] 04:02:40,823 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-3) ARJUNA012343: RecoveryManagerImple is ready. Socket listener is turned off.
> [Server:failover-three] 04:02:40,823 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032013: Starting transaction recovery manager
> [Server:failover-three] 04:02:40,937 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-6) ARJUNA032017: JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-three] 04:02:41,088 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [Server:failover-three] 04:02:41,135 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-5) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:5995 for CORE protocol
> [Server:failover-three] 04:02:41,143 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-5) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:6005 for CORE protocol
> [Server:failover-three] 04:02:41,147 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-5) Server is now live
> [Server:failover-three] 04:02:41,149 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-5) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [c34b0bab-de0a-11e1-8976-f9b7adac47b8]) started
> [Server:failover-three] 04:02:41,185 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 54) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> [Server:failover-three] 04:02:41,188 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 56) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
> [Server:failover-three] 04:02:41,193 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 57) trying to deploy queue jms.queue.testQueue
> [Server:failover-three] 04:02:41,296 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 57) JBAS011601: Bound messaging object to jndi name java:/queue/test
> [Server:failover-three] 04:02:41,297 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 55) trying to deploy queue jms.topic.testTopic
> [Server:failover-three] 04:02:41,332 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 55) JBAS011601: Bound messaging object to jndi name java:/topic/test
> [Server:failover-three] 04:02:41,353 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010406: Registered connection factory java:/JmsXA
> [Server:failover-three] 04:02:41,415 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-4) HornetQ resource adaptor started
> [Server:failover-three] 04:02:41,415 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra
> [Server:failover-three] 04:02:41,421 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> [Server:failover-three] 04:02:41,893 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> [Server:failover-three] JBAS014775:    New missing/unsatisfied dependencies:
> [Server:failover-three]       service jboss.server.controller.management.security_realm.ApplicationRealm (missing) dependents: [service jboss.remoting.authentication_provider.remoting-connector] 
> [Server:failover-three] 
> [Server:failover-three] 04:02:41,912 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 5430ms - Started 138 of 221 services (4 services failed or missing dependencies, 78 services are passive or on-demand)
> [Host Controller] 04:02:41,925 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-three
> [Host Controller] 04:02:43,393 WARN  [org.jboss.as.host.controller] (Remoting "jenkins-slave3:MANAGEMENT" task-2) JBAS010914: Connection to remote host-controller closed. Trying to reconnect.
> [Host Controller] 04:02:43,442 WARN  [org.jboss.as.host.controller] (Remoting "jenkins-slave3:MANAGEMENT" read-1) JBAS010914: Connection to remote host-controller closed. Trying to reconnect.
> [Host Controller] 04:02:44,195 INFO  [org.jboss.as.host.controller] (MSC service thread 1-4) JBAS010926: Unregistering server failover-two
> [Host Controller] 04:02:48,486 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" stopped in 4325ms
> [Host Controller] 04:02:48,491 INFO  [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:48,572 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (9980) securePort (-1)
> [Host Controller] 04:02:48,594 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on [fccc::2]:9989
> [Host Controller] 04:02:48,702 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,042 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:49,087 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,097 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:49,099 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,100 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,102 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,103 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,104 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,106 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,474 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010917: Reconnecting server failover-two
> [Host Controller] 04:02:49,571 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-two] registered using connection [Channel ID 3e69e717 (inbound) of Remoting connection 349d963f to /fccc:0:0:0:0:0:0:2:47499]
> [Host Controller] 04:02:49,646 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-two
> [Host Controller] 04:02:49,652 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:9980/management
> [Host Controller] 04:02:49,653 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://fccc::2:9980
> [Host Controller] 04:02:49,654 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 1159ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Host Controller] 04:02:54,946 INFO  [org.jboss.as.host.controller] (MSC service thread 1-1) JBAS010926: Unregistering server failover-three
> [Host Controller] 04:02:55,026 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015950: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" stopped in 126ms
> [Host Controller] 04:02:55,029 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:55,115 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (19990) securePort (-1)
> [Host Controller] 04:02:55,135 INFO  [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on [fccc::2]:19999
> [Host Controller] 04:02:55,709 INFO  [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "failover3", JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes"
> [Host Controller] 04:02:55,843 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:19990/management
> [Host Controller] 04:02:55,845 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015954: Admin console is not enabled
> [Host Controller] 04:02:55,846 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 813ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Host Controller] 04:03:01,118 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/data/content/cc/b78b5f0fba55537206b3b35588797dd288a9c6/content
> [Server:failover-two] 04:03:01,634 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "SimpleServlet.war"
> [Server:failover-two] 04:03:02,267 INFO  [org.jboss.web] (MSC service thread 1-4) JBAS018210: Register web context: /SimpleServlet
> [Server:failover-two] 04:03:02,765 INFO  [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018559: Deployed "SimpleServlet.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 issues at jboss.org  Mon Jan 20 15:54:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Mon, 20 Jan 2014 15:54:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5306)
 DomainControllerMigrationTestCase.testDCFailover intermittently fails
In-Reply-To: <JIRA.12471817.1344078762000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471817.1344078762000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471817.1344078762000.2706.1390251269277@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937319#comment-12937319 ] 

Aleksandar Kostadinov commented on AS7-5306:
--------------------------------------------

Excuse me and please ignore, I posted to the wrong issue.
                
> DomainControllerMigrationTestCase.testDCFailover intermittently fails
> ---------------------------------------------------------------------
>
>                 Key: AS7-5306
>                 URL: https://issues.jboss.org/browse/AS7-5306
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 7.1.3.Final (EAP)
>            Reporter: Kabir Khan
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> Stacktrace
> {code}
> junit.framework.AssertionFailedError
> 	at junit.framework.Assert.fail(Assert.java:48)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertTrue(Assert.java:27)
> 	at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:209)
> 	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:45)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 	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.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Standard Output
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/domain-configs/domain-standard.xml
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/host-configs/host-failover1.xml
> 04:02:08,268 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> 04:02:08,383 INFO  [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 04:02:08,866 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Host Controller] 04:02:09,068 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Host Controller] 04:02:09,139 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:09,998 INFO  [org.xnio] (MSC service thread 1-3) XNIO Version 3.0.5.GA
> [Host Controller] 04:02:10,006 INFO  [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.0.5.GA
> [Host Controller] 04:02:10,016 INFO  [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:10,071 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (9990) securePort (-1)
> [Host Controller] 04:02:10,236 INFO  [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on [::1]:9999
> [Host Controller] 04:02:10,869 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,432 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:11,493 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,504 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:11,506 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,507 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,509 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,510 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,511 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:11,513 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:12,204 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server failover-one
> 04:02:12,264 INFO  [org.jboss.as.process.Server:failover-one.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:failover-one'
> [Host Controller] 04:02:12,364 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://::1:9990/management
> [Host Controller] 04:02:12,366 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://::1:9990
> [Host Controller] 04:02:12,367 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 3882ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Server:failover-one] 04:02:13,073 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Server:failover-one] 04:02:13,405 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Server:failover-one] 04:02:13,505 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Server:failover-one] 04:02:13,625 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.5.GA
> [Server:failover-one] 04:02:13,637 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.5.GA
> [Server:failover-one] 04:02:13,664 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:15,369 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-one] registered using connection [Channel ID 46504c6e (inbound) of Remoting connection 0b412c18 to /0:0:0:0:0:0:0:1:52549]
> [Server:failover-one] 04:02:15,387 INFO  [org.jboss.as.logging] (MSC service thread 1-1) JBAS011502: Removing bootstrap log handlers
> [Server:failover-one] 04:02:15,402 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 29) JBAS015537: Activating WebServices Extension
> [Server:failover-one] 04:02:15,413 INFO  [org.jboss.as.modcluster] (ServerService Thread Pool -- 28) JBAS011704: Mod_cluster uses default load balancer provider
> [Server:failover-one] 04:02:15,459 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [Server:failover-one] 04:02:15,551 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> [Server:failover-one] 04:02:15,557 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) JBAS010260: Activating JGroups subsystem.
> [Server:failover-one] 04:02:15,559 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [Server:failover-one] 04:02:15,649 INFO  [org.jboss.as.security] (MSC service thread 1-6) JBAS013170: Current PicketBox version=4.0.9.Final
> [Server:failover-one] 04:02:15,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 47) JBAS010280: Activating Infinispan subsystem.
> [Server:failover-one] 04:02:15,689 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [Server:failover-one] 04:02:15,907 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> [Server:failover-one] 04:02:15,948 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [Server:failover-one] 04:02:16,037 INFO  [org.jboss.jaxr] (MSC service thread 1-2) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
> [Server:failover-one] 04:02:16,150 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-5) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> [Server:failover-one] 04:02:16,870 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032010: JBossTS Recovery Service (tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-one] 04:02:16,975 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012324: Start RecoveryActivators
> [Server:failover-one] 04:02:17,040 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-one] 04:02:17,052 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-one] 04:02:17,256 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-localhost/0:0:0:0:0:0:0:1%1:8009
> [Server:failover-one] 04:02:17,288 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http-localhost/0:0:0:0:0:0:0:1%1:8080
> [Server:failover-one] 04:02:17,272 INFO  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012296: ExpiredEntryMonitor running at Sat, 4 Aug 2012 04:02:17
> [Server:failover-one] 04:02:17,472 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messagingjournal,bindingsDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messagingbindings,largeMessagesDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messaginglargemessages,pagingDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover1/servers/failover-one/data/messagingpaging)
> [Server:failover-one] 04:02:17,483 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.1.Final
> [Server:failover-one] 04:02:17,523 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 54) Listening to proxy advertisements on 224.0.1.105:23,364
> [Server:failover-one] 04:02:17,685 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c 0:0:0:0:0:0:0:1%1:5445 for CORE protocol
> [Server:failover-one] 04:02:17,706 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c 0:0:0:0:0:0:0:1%1:5455 for CORE protocol
> [Server:failover-one] 04:02:17,721 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012343: RecoveryManagerImple is ready. Socket listener is turned off.
> [Server:failover-one] 04:02:17,725 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) Server is now live
> [Server:failover-one] 04:02:17,730 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032013: Starting transaction recovery manager
> [Server:failover-one] 04:02:17,730 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [b585cf0b-de0a-11e1-839e-7305fde0f34e]) started
> [Server:failover-one] 04:02:17,938 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-2) ARJUNA032017: JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-one] 04:02:17,955 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 54) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> [Server:failover-one] 04:02:17,962 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 57) trying to deploy queue jms.topic.testTopic
> [Server:failover-one] 04:02:18,164 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [Server:failover-one] 04:02:18,210 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-5) JBAS010406: Registered connection factory java:/JmsXA
> [Server:failover-one] 04:02:18,203 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 57) JBAS011601: Bound messaging object to jndi name java:/topic/test
> [Server:failover-one] 04:02:18,226 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 56) trying to deploy queue jms.queue.testQueue
> [Server:failover-one] 04:02:18,259 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 56) JBAS011601: Bound messaging object to jndi name java:/queue/test
> [Server:failover-one] 04:02:18,261 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 55) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
> [Server:failover-one] 04:02:18,302 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-5) HornetQ resource adaptor started
> [Server:failover-one] 04:02:18,303 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-5) IJ020002: Deployed: file://RaActivatorhornetq-ra
> [Server:failover-one] 04:02:18,309 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> [Server:failover-one] 04:02:18,764 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> [Server:failover-one] JBAS014775:    New missing/unsatisfied dependencies:
> [Server:failover-one]       service jboss.server.controller.management.security_realm.ApplicationRealm (missing) dependents: [service jboss.remoting.authentication_provider.remoting-connector] 
> [Server:failover-one] 
> [Server:failover-one] 04:02:18,779 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 6253ms - Started 138 of 221 services (4 services failed or missing dependencies, 78 services are passive or on-demand)
> [Host Controller] 04:02:18,792 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-one
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/domain-configs/domain-standard.xml
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/host-configs/host-failover2.xml
> 04:02:19,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> 04:02:19,835 INFO  [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 04:02:20,446 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Host Controller] 04:02:20,653 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Host Controller] 04:02:20,803 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:22,015 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (9980) securePort (-1)
> [Host Controller] 04:02:22,015 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.5.GA
> [Host Controller] 04:02:22,059 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.5.GA
> [Host Controller] 04:02:22,102 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:22,319 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on [fccc::2]:9989
> [Host Controller] 04:02:24,415 INFO  [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "failover2", JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes"
> [Host Controller] 04:02:24,662 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server failover-two
> 04:02:24,724 INFO  [org.jboss.as.process.Server:failover-two.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:failover-two'
> [Host Controller] 04:02:24,734 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:9980/management
> [Host Controller] 04:02:24,736 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015954: Admin console is not enabled
> [Host Controller] 04:02:24,737 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 4798ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Server:failover-two] 04:02:25,479 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Server:failover-two] 04:02:25,808 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Server:failover-two] 04:02:26,014 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Server:failover-two] 04:02:26,324 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.5.GA
> [Server:failover-two] 04:02:26,355 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.5.GA
> [Server:failover-two] 04:02:26,386 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:27,913 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-two] registered using connection [Channel ID 28a61589 (inbound) of Remoting connection 21044daf to /fccc:0:0:0:0:0:0:2:54201]
> [Server:failover-two] 04:02:27,971 INFO  [org.jboss.as.logging] (MSC service thread 1-5) JBAS011502: Removing bootstrap log handlers
> [Server:failover-two] 04:02:27,986 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 29) JBAS015537: Activating WebServices Extension
> [Server:failover-two] 04:02:27,990 INFO  [org.jboss.as.modcluster] (ServerService Thread Pool -- 28) JBAS011704: Mod_cluster uses default load balancer provider
> [Server:failover-two] 04:02:28,060 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [Server:failover-two] 04:02:28,066 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [Server:failover-two] 04:02:28,101 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> [Server:failover-two] 04:02:28,125 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) JBAS010260: Activating JGroups subsystem.
> [Server:failover-two] 04:02:28,142 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-3) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [Server:failover-two] 04:02:28,148 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 47) JBAS010280: Activating Infinispan subsystem.
> [Server:failover-two] 04:02:28,161 INFO  [org.jboss.as.security] (MSC service thread 1-2) JBAS013170: Current PicketBox version=4.0.9.Final
> [Server:failover-two] 04:02:28,275 INFO  [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> [Server:failover-two] 04:02:28,329 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [Server:failover-two] 04:02:28,452 INFO  [org.jboss.jaxr] (MSC service thread 1-4) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
> [Server:failover-two] 04:02:28,567 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> [Server:failover-two] 04:02:29,090 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http-/fccc:0:0:0:0:0:0:2%1:8430
> [Server:failover-two] 04:02:29,114 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-two] 04:02:29,120 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-two] 04:02:29,105 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-6) Starting Coyote AJP/1.3 on ajp-/fccc:0:0:0:0:0:0:2%1:8359
> [Server:failover-two] 04:02:29,261 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032010: JBossTS Recovery Service (tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-two] 04:02:29,317 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messagingjournal,bindingsDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messagingbindings,largeMessagesDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messaginglargemessages,pagingDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/servers/failover-two/data/messagingpaging)
> [Server:failover-two] 04:02:29,318 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012324: Start RecoveryActivators
> [Server:failover-two] 04:02:29,380 INFO  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012296: ExpiredEntryMonitor running at Sat, 4 Aug 2012 04:02:29
> [Server:failover-two] 04:02:29,512 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.1.Final
> [Server:failover-two] 04:02:29,587 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-1) ARJUNA012343: RecoveryManagerImple is ready. Socket listener is turned off.
> [Server:failover-two] 04:02:29,589 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-1) ARJUNA032013: Starting transaction recovery manager
> [Server:failover-two] 04:02:29,607 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 54) Listening to proxy advertisements on 224.0.1.105:23,364
> [Server:failover-two] 04:02:29,821 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-5) ARJUNA032017: JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-two] 04:02:29,941 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:5795 for CORE protocol
> [Server:failover-two] 04:02:29,955 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:5805 for CORE protocol
> [Server:failover-two] 04:02:29,957 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) Server is now live
> [Server:failover-two] 04:02:29,957 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [bc931309-de0a-11e1-bf84-3397a847e4d3]) started
> [Server:failover-two] 04:02:29,977 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [Server:failover-two] 04:02:30,057 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 54) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
> [Server:failover-two] 04:02:30,060 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 57) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> [Server:failover-two] 04:02:30,062 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 56) trying to deploy queue jms.queue.testQueue
> [Server:failover-two] 04:02:30,091 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-6) JBAS010406: Registered connection factory java:/JmsXA
> [Server:failover-two] 04:02:30,171 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-6) HornetQ resource adaptor started
> [Server:failover-two] 04:02:30,172 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-6) IJ020002: Deployed: file://RaActivatorhornetq-ra
> [Server:failover-two] 04:02:30,176 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> [Server:failover-two] 04:02:30,185 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 56) JBAS011601: Bound messaging object to jndi name java:/queue/test
> [Server:failover-two] 04:02:30,187 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 55) trying to deploy queue jms.topic.testTopic
> [Server:failover-two] 04:02:30,241 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 55) JBAS011601: Bound messaging object to jndi name java:/topic/test
> [Server:failover-two] 04:02:30,719 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> [Server:failover-two] JBAS014775:    New missing/unsatisfied dependencies:
> [Server:failover-two]       service jboss.server.controller.management.security_realm.ApplicationRealm (missing) dependents: [service jboss.remoting.authentication_provider.remoting-connector] 
> [Server:failover-two] 
> [Server:failover-two] 04:02:30,808 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 5937ms - Started 138 of 221 services (4 services failed or missing dependencies, 78 services are passive or on-demand)
> [Host Controller] 04:02:30,820 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-two
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/domain-configs/domain-standard.xml
> /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/test-classes/host-configs/host-failover3.xml
> 04:02:31,516 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> 04:02:31,632 INFO  [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 04:02:32,148 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Host Controller] 04:02:32,330 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Host Controller] 04:02:32,399 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:32,904 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (19990) securePort (-1)
> [Host Controller] 04:02:32,906 INFO  [org.xnio] (MSC service thread 1-6) XNIO Version 3.0.5.GA
> [Host Controller] 04:02:32,933 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.0.5.GA
> [Host Controller] 04:02:32,943 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:33,109 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on [fccc::2]:19999
> [Host Controller] 04:02:36,061 INFO  [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "failover3", JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes"
> [Host Controller] 04:02:36,206 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010922: Starting server failover-three
> 04:02:36,263 INFO  [org.jboss.as.process.Server:failover-three.status] (ProcessController-threads - 3) JBAS012017: Starting process 'Server:failover-three'
> [Host Controller] 04:02:36,274 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:19990/management
> [Host Controller] 04:02:36,277 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015954: Admin console is not enabled
> [Host Controller] 04:02:36,277 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 4533ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Server:failover-three] 04:02:36,910 INFO  [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA
> [Server:failover-three] 04:02:37,319 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
> [Server:failover-three] 04:02:37,531 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Server:failover-three] 04:02:37,828 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.5.GA
> [Server:failover-three] 04:02:37,848 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.5.GA
> [Server:failover-three] 04:02:37,858 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.8.GA
> [Host Controller] 04:02:39,255 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-three] registered using connection [Channel ID 354ca75c (inbound) of Remoting connection 5fb57890 to /fccc:0:0:0:0:0:0:2:35193]
> [Server:failover-three] 04:02:39,425 INFO  [org.jboss.as.logging] (MSC service thread 1-5) JBAS011502: Removing bootstrap log handlers
> [Server:failover-three] 04:02:39,445 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 29) JBAS015537: Activating WebServices Extension
> [Server:failover-three] 04:02:39,491 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 33) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> [Server:failover-three] 04:02:39,494 INFO  [org.jboss.as.modcluster] (ServerService Thread Pool -- 28) JBAS011704: Mod_cluster uses default load balancer provider
> [Server:failover-three] 04:02:39,498 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> [Server:failover-three] 04:02:39,512 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 46) JBAS010260: Activating JGroups subsystem.
> [Server:failover-three] 04:02:39,525 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> [Server:failover-three] 04:02:39,543 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 47) JBAS010280: Activating Infinispan subsystem.
> [Server:failover-three] 04:02:39,651 INFO  [org.jboss.as.security] (MSC service thread 1-6) JBAS013170: Current PicketBox version=4.0.9.Final
> [Server:failover-three] 04:02:39,824 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> [Server:failover-three] 04:02:39,981 INFO  [org.jboss.as.naming] (MSC service thread 1-6) JBAS011802: Starting Naming Service
> [Server:failover-three] 04:02:40,012 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
> [Server:failover-three] 04:02:40,033 INFO  [org.jboss.jaxr] (MSC service thread 1-4) JBAS014000: Started JAXR subsystem, binding JAXR connection factory into JNDI as: java:jboss/jaxr/ConnectionFactory
> [Server:failover-three] 04:02:40,127 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-2) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> [Server:failover-three] 04:02:40,332 INFO  [org.apache.coyote.ajp.AjpAprProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-/fccc:0:0:0:0:0:0:2%1:8559
> [Server:failover-three] 04:02:40,372 INFO  [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/fccc:0:0:0:0:0:0:2%1:8630
> [Server:failover-three] 04:02:40,430 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032010: JBossTS Recovery Service (tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-three] 04:02:40,490 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.1.Final
> [Server:failover-three] 04:02:40,614 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-5) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messagingjournal,bindingsDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messagingbindings,largeMessagesDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messaginglargemessages,pagingDirectory=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover3/servers/failover-three/data/messagingpaging)
> [Server:failover-three] 04:02:40,625 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-3) ARJUNA012324: Start RecoveryActivators
> [Server:failover-three] 04:02:40,626 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-three] 04:02:40,637 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 54) Listening to proxy advertisements on 224.0.1.105:23,364
> [Server:failover-three] 04:02:40,659 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 47) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [Server:failover-three] 04:02:40,707 INFO  [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) ARJUNA012296: ExpiredEntryMonitor running at Sat, 4 Aug 2012 04:02:40
> [Server:failover-three] 04:02:40,823 INFO  [com.arjuna.ats.arjuna] (MSC service thread 1-3) ARJUNA012343: RecoveryManagerImple is ready. Socket listener is turned off.
> [Server:failover-three] 04:02:40,823 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032013: Starting transaction recovery manager
> [Server:failover-three] 04:02:40,937 INFO  [com.arjuna.ats.jbossatx] (MSC service thread 1-6) ARJUNA032017: JBossTS Transaction Service (JTA version - tag: JBOSSTS_4_16_4_Final) - JBoss Inc.
> [Server:failover-three] 04:02:41,088 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> [Server:failover-three] 04:02:41,135 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-5) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:5995 for CORE protocol
> [Server:failover-three] 04:02:41,143 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-5) Started Netty Acceptor version 3.2.5.Final-a96d88c fccc:0:0:0:0:0:0:2%1:6005 for CORE protocol
> [Server:failover-three] 04:02:41,147 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-5) Server is now live
> [Server:failover-three] 04:02:41,149 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-5) HornetQ Server version 2.2.18.Final (HQ_2_2_18_FINAL, 122) [c34b0bab-de0a-11e1-8976-f9b7adac47b8]) started
> [Server:failover-three] 04:02:41,185 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 54) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
> [Server:failover-three] 04:02:41,188 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 56) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
> [Server:failover-three] 04:02:41,193 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 57) trying to deploy queue jms.queue.testQueue
> [Server:failover-three] 04:02:41,296 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 57) JBAS011601: Bound messaging object to jndi name java:/queue/test
> [Server:failover-three] 04:02:41,297 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (ServerService Thread Pool -- 55) trying to deploy queue jms.topic.testTopic
> [Server:failover-three] 04:02:41,332 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 55) JBAS011601: Bound messaging object to jndi name java:/topic/test
> [Server:failover-three] 04:02:41,353 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010406: Registered connection factory java:/JmsXA
> [Server:failover-three] 04:02:41,415 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-4) HornetQ resource adaptor started
> [Server:failover-three] 04:02:41,415 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra
> [Server:failover-three] 04:02:41,421 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
> [Server:failover-three] 04:02:41,893 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> [Server:failover-three] JBAS014775:    New missing/unsatisfied dependencies:
> [Server:failover-three]       service jboss.server.controller.management.security_realm.ApplicationRealm (missing) dependents: [service jboss.remoting.authentication_provider.remoting-connector] 
> [Server:failover-three] 
> [Server:failover-three] 04:02:41,912 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 5430ms - Started 138 of 221 services (4 services failed or missing dependencies, 78 services are passive or on-demand)
> [Host Controller] 04:02:41,925 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-three
> [Host Controller] 04:02:43,393 WARN  [org.jboss.as.host.controller] (Remoting "jenkins-slave3:MANAGEMENT" task-2) JBAS010914: Connection to remote host-controller closed. Trying to reconnect.
> [Host Controller] 04:02:43,442 WARN  [org.jboss.as.host.controller] (Remoting "jenkins-slave3:MANAGEMENT" read-1) JBAS010914: Connection to remote host-controller closed. Trying to reconnect.
> [Host Controller] 04:02:44,195 INFO  [org.jboss.as.host.controller] (MSC service thread 1-4) JBAS010926: Unregistering server failover-two
> [Host Controller] 04:02:48,486 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" stopped in 4325ms
> [Host Controller] 04:02:48,491 INFO  [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:48,572 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (9980) securePort (-1)
> [Host Controller] 04:02:48,594 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on [fccc::2]:9989
> [Host Controller] 04:02:48,702 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,042 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:49,087 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,097 WARN  [org.jboss.as.jmx] (Controller Boot Thread) JBAS011305: <jmx-connector/> is no longer supporting. <remoting-connector/> should be used instead to allow remote connections via JBoss Remoting.
> [Host Controller] 04:02:49,099 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,100 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,102 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,103 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,104 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,106 WARN  [org.jboss.as.threads] (Controller Boot Thread) JBAS012400: The 'per-cpu' attribute is no longer supported. The value [10.000000] of the 'count' attribute is being combined with the value [20.000000] of the 'per-cpu' attribute and the current processor count [3] to derive a new value of [70] for 'count'.
> [Host Controller] 04:02:49,474 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010917: Reconnecting server failover-two
> [Host Controller] 04:02:49,571 INFO  [org.jboss.as.domain.controller.mgmt] (proxy-threads - 1) JBAS010920: Server [Server:failover-two] registered using connection [Channel ID 3e69e717 (inbound) of Remoting connection 349d963f to /fccc:0:0:0:0:0:0:2:47499]
> [Host Controller] 04:02:49,646 INFO  [org.jboss.as.host.controller] (proxy-threads - 1) JBAS010919: Registering server failover-two
> [Host Controller] 04:02:49,652 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:9980/management
> [Host Controller] 04:02:49,653 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://fccc::2:9980
> [Host Controller] 04:02:49,654 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 1159ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Host Controller] 04:02:54,946 INFO  [org.jboss.as.host.controller] (MSC service thread 1-1) JBAS010926: Unregistering server failover-three
> [Host Controller] 04:02:55,026 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015950: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" stopped in 126ms
> [Host Controller] 04:02:55,029 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> [Host Controller] 04:02:55,115 INFO  [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (public) port (19990) securePort (-1)
> [Host Controller] 04:02:55,135 INFO  [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on [fccc::2]:19999
> [Host Controller] 04:02:55,709 INFO  [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "failover3", JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes"
> [Host Controller] 04:02:55,843 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::2:19990/management
> [Host Controller] 04:02:55,845 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015954: Admin console is not enabled
> [Host Controller] 04:02:55,846 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" (Host Controller) started in 813ms - Started 11 of 11 services (0 services are passive or on-demand)
> [Host Controller] 04:03:01,118 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/domain/target/domains/DomainControllerMigrationTestCase/failover2/data/content/cc/b78b5f0fba55537206b3b35588797dd288a9c6/content
> [Server:failover-two] 04:03:01,634 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "SimpleServlet.war"
> [Server:failover-two] 04:03:02,267 INFO  [org.jboss.web] (MSC service thread 1-4) JBAS018210: Register web context: /SimpleServlet
> [Server:failover-two] 04:03:02,765 INFO  [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018559: Deployed "SimpleServlet.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 issues at jboss.org  Mon Jan 20 17:10:28 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 20 Jan 2014 17:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2488) Adding a datasource fails in
 a composite operation
In-Reply-To: <JIRA.12524806.1384188210000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524806.1384188210000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524806.1384188210000.3040.1390255828808@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFLY-2488.
-------------------------------

    Resolution: Out of Date


Seems to be fixed in WildFly and shouldn't require an enable for the {{wildfly-maven-plugin}}.
                
> Adding a datasource fails in a composite operation
> --------------------------------------------------
>
>                 Key: WFLY-2488
>                 URL: https://issues.jboss.org/browse/WFLY-2488
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: James Perkins
>            Assignee: Stefano Maestri
>         Attachments: wfly2488-sources.jar, wfly2488.jar
>
>
> Executing a composite operation fails when adding a datasource.
> Stack Trace:
> {code}
> 08:38:49,787 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) JBAS014612: Operation ("add") failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "ds-test")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.ds-test 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.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [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.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1422) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> 	at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 	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 issues at jboss.org  Mon Jan 20 17:18:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.3056.1390256310753@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937331#comment-12937331 ] 

RH Bugzilla Integration commented on WFLY-2513:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1051205|https://bugzilla.redhat.com/show_bug.cgi?id=1051205] from MODIFIED to ON_QA
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Mon Jan 20 17:18:31 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2633) Cannot use deployments with
 same runtime-name in a domain
In-Reply-To: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527605.1386720363000.3063.1390256311043@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937334#comment-12937334 ] 

RH Bugzilla Integration commented on WFLY-2633:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1039699|https://bugzilla.redhat.com/show_bug.cgi?id=1039699] from MODIFIED to ON_QA
                
> Cannot use deployments with same runtime-name in a domain
> ---------------------------------------------------------
>
>                 Key: WFLY-2633
>                 URL: https://issues.jboss.org/browse/WFLY-2633
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The check for duplicate runtime-name in a server group on startup is too aggressive.  It is incorrectly throwing an error on startup if there are any duplicate runtime-names in the whole domain, instead of just in a single server group.
> Steps to Reproduce:
> 1.  Start a single HC/DC
> 2.  deploy --name=foo1 --runtime-name=bar --disabled testfile
> 3.  deploy --name=foo2 --runtime-name=bar --disabled testfile
> 4.  restart the DC/HC
> Actual results:
> JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> ...
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9]
> ...
> Message: JBAS014664: An element of this type named 'bar' has already been declared
> Expected results:
> No errors

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:31 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.3080.1390256311872@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937340#comment-12937340 ] 

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from MODIFIED to ON_QA
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Mon Jan 20 17:18:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.3087.1390256312177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937342#comment-12937342 ] 

RH Bugzilla Integration commented on WFLY-2660:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1051240|https://bugzilla.redhat.com/show_bug.cgi?id=1051240] from MODIFIED to ON_QA
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.3091.1390256312354@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937343#comment-12937343 ] 

RH Bugzilla Integration commented on WFLY-2595:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1049074|https://bugzilla.redhat.com/show_bug.cgi?id=1049074] from MODIFIED to ON_QA
                
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.3097.1390256312625@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937345#comment-12937345 ] 

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from MODIFIED to ON_QA
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager
 module needs a dependency on javax.mail.api
In-Reply-To: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490786.1367277432000.3106.1390256313018@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937349#comment-12937349 ] 

RH Bugzilla Integration commented on WFLY-1300:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1051335|https://bugzilla.redhat.com/show_bug.cgi?id=1051335] from MODIFIED to ON_QA
                
> org.jboss.log4j.logmanager module needs a dependency on javax.mail.api
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1300
>                 URL: https://issues.jboss.org/browse/WFLY-1300
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.3100.1390256312747@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937346#comment-12937346 ] 

RH Bugzilla Integration commented on WFLY-2753:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1053382|https://bugzilla.redhat.com/show_bug.cgi?id=1053382] from MODIFIED to ON_QA
                
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2514) Using directory grouping
 by-type results in the wrong logging.properties file being used
In-Reply-To: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525194.1384479524000.3120.1390256313630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937353#comment-12937353 ] 

RH Bugzilla Integration commented on WFLY-2514:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1050068|https://bugzilla.redhat.com/show_bug.cgi?id=1050068] from MODIFIED to ON_QA
                
> Using directory grouping by-type results in the wrong logging.properties file being used
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2514
>                 URL: https://issues.jboss.org/browse/WFLY-2514
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> When defining servers with {{directory-grouping="by-type"}} the wrong directory is used in the {{ManagedServerBootCmdFactory}}. This causes the {{domain/configuration/logging.properties}} to always be used which is the incorrect configuration to use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:33 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS /
 Hibernate JPA integration
In-Reply-To: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526628.1385994740000.3125.1390256313824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937354#comment-12937354 ] 

RH Bugzilla Integration commented on WFLY-2593:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1037636|https://bugzilla.redhat.com/show_bug.cgi?id=1037636] from MODIFIED to ON_QA
                
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
>                 Key: WFLY-2593
>                 URL: https://issues.jboss.org/browse/WFLY-2593
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: No Release
>         Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
>            Reporter: Michael Kozak
>            Assignee: Scott Marlow
>            Priority: Critical
>             Fix For: No Release
>
>         Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA. 
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2616) SEVERE is not an available
 logging level in the CLI
In-Reply-To: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527159.1386289598000.3133.1390256314157@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937357#comment-12937357 ] 

RH Bugzilla Integration commented on WFLY-2616:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1038862|https://bugzilla.redhat.com/show_bug.cgi?id=1038862] from MODIFIED to ON_QA
                
> SEVERE is not an available logging level in the CLI
> ---------------------------------------------------
>
>                 Key: WFLY-2616
>                 URL: https://issues.jboss.org/browse/WFLY-2616
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Kyle Lape
>            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 issues at jboss.org  Mon Jan 20 17:18:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError:
 expected:<200> but was:<500>' in
 org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
In-Reply-To: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527235.1386342825000.3136.1390256314355@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937358#comment-12937358 ] 

RH Bugzilla Integration commented on WFLY-2618:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1049796|https://bugzilla.redhat.com/show_bug.cgi?id=1049796] from MODIFIED to ON_QA
                
> Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2618
>                 URL: https://issues.jboss.org/browse/WFLY-2618
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-3843551226685549253&tab=testDetails
> The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.3149.1390256314963@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937362#comment-12937362 ] 

RH Bugzilla Integration commented on WFLY-2696:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1047536|https://bugzilla.redhat.com/show_bug.cgi?id=1047536] from MODIFIED to ON_QA
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:34 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.3146.1390256314845@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937361#comment-12937361 ] 

RH Bugzilla Integration commented on WFLY-2498:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1051171|https://bugzilla.redhat.com/show_bug.cgi?id=1051171] from MODIFIED to ON_QA
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Mon Jan 20 17:18:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.3154.1390256315286@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937363#comment-12937363 ] 

RH Bugzilla Integration commented on WFLY-2725:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1050003|https://bugzilla.redhat.com/show_bug.cgi?id=1050003] from MODIFIED to ON_QA
                
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Mon Jan 20 17:18:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.3159.1390256315464@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937364#comment-12937364 ] 

RH Bugzilla Integration commented on WFLY-1594:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1051189|https://bugzilla.redhat.com/show_bug.cgi?id=1051189] from MODIFIED to ON_QA
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 17:18:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 17:18:35 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-89) LogContext's root logger is
 not created with a strong child hash map when strong=true
In-Reply-To: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525357.1384544962000.3164.1390256315677@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937365#comment-12937365 ] 

RH Bugzilla Integration commented on LOGMGR-89:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1031221|https://bugzilla.redhat.com/show_bug.cgi?id=1031221] from MODIFIED to ON_QA
                
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-89
>                 URL: https://issues.jboss.org/browse/LOGMGR-89
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>             Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
>   <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <logger name="com.redhat" additivity="false">
>     <level value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP_MDB"/>
>   </logger>
>   <root>
>     <priority value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP"/>
>   </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used.  One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO  [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {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 issues at jboss.org  Mon Jan 20 18:02:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 18:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.3228.1390258948661@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937373#comment-12937373 ] 

RH Bugzilla Integration commented on WFLY-2782:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1055740|https://bugzilla.redhat.com/show_bug.cgi?id=1055740] from NEW to POST
                
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 20 18:02:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Jan 2014 18:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.3230.1390258948753@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937374#comment-12937374 ] 

RH Bugzilla Integration commented on WFLY-2782:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1055740|https://bugzilla.redhat.com/show_bug.cgi?id=1055740] from POST to MODIFIED
                
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 02:16:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 02:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-958) There's no way to enforce
 security on an in-vm connection in AS7
In-Reply-To: <JIRA.12467594.1338320806000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467594.1338320806000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467594.1338320806000.3517.1390288589573@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-958:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1040611

    
> There's no way to enforce security on an in-vm connection in AS7
> ----------------------------------------------------------------
>
>                 Key: WFLY-958
>                 URL: https://issues.jboss.org/browse/WFLY-958
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Justin Bertram
>            Assignee: Jeff Mesnil
>
> When AS7 starts org.jboss.as.messaging.jms.JMSService sets up a default security override for in-vm connections.  There is no way to disable this override and there should be.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 02:36:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 02:36:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2513) BDA ID contains absolute the
 path of the deployment location
In-Reply-To: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525164.1384448581000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525164.1384448581000.3521.1390289788543@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937408#comment-12937408 ] 

RH Bugzilla Integration commented on WFLY-2513:
-----------------------------------------------

Ron ?meral <rsmeral at redhat.com> changed the Status of [bug 1051205|https://bugzilla.redhat.com/show_bug.cgi?id=1051205] from ON_QA to VERIFIED
                
> BDA ID contains absolute the path of the deployment location
> ------------------------------------------------------------
>
>                 Key: WFLY-2513
>                 URL: https://issues.jboss.org/browse/WFLY-2513
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             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 issues at jboss.org  Tue Jan 21 02:58:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Tue, 21 Jan 2014 02:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.3538.1390291108807@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937409#comment-12937409 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

I just verified that it is the same JVM. If I shall run it with any other options etc just let me know!
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 03:08:28 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Tue, 21 Jan 2014 03:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2439) Arquillian Wildfly Managed -
 support exploded mode
In-Reply-To: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518015.1383653230000.3571.1390291708841@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937414#comment-12937414 ] 

Max Rydahl Andersen commented on WFLY-2439:
-------------------------------------------

I think what he means is that the testsuite of wildfly should have tests to cover the usecase of exploded mode but since the testsuite relies on arquillian to do the deployment this is not possible to actually test. Hence why suggestion is to add exploded support to arquillian to allow for this feature of the appserver to be tested.
                
> Arquillian Wildfly Managed - support exploded mode
> --------------------------------------------------
>
>                 Key: WFLY-2439
>                 URL: https://issues.jboss.org/browse/WFLY-2439
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Zizka
>              Labels: arquillian
>
> Arquillian WildFly managed container currently doesn't support exploded mode deployment. JBDS supports it through moving the files to the standalone/deployments dir. It would be nice if we could add some tests covering this to the WildFly testsuite.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 03:10:28 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Tue, 21 Jan 2014 03:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2439) Arquillian Wildfly Managed -
 support exploded mode
In-Reply-To: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518015.1383653230000.3575.1390291828707@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937416#comment-12937416 ] 

Max Rydahl Andersen commented on WFLY-2439:
-------------------------------------------

This relates to wildfly team asking us to add tests for exploded deployment so it does not break between releases and when I ask where we are pointed to the arquillian test suite....which does not support testing this ...hence this suggestion to make it possible.
                
> Arquillian Wildfly Managed - support exploded mode
> --------------------------------------------------
>
>                 Key: WFLY-2439
>                 URL: https://issues.jboss.org/browse/WFLY-2439
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Zizka
>              Labels: arquillian
>
> Arquillian WildFly managed container currently doesn't support exploded mode deployment. JBDS supports it through moving the files to the standalone/deployments dir. It would be nice if we could add some tests covering this to the WildFly testsuite.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 03:20:29 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Tue, 21 Jan 2014 03:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2427) Launcher API
In-Reply-To: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509240.1383251005000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509240.1383251005000.3622.1390292429254@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937424#comment-12937424 ] 

Max Rydahl Andersen commented on WFLY-2427:
-------------------------------------------

[~bstansberry] that sounds great - it would be great if we could get the information used to build processbuilder so we can pass the various separate parts to the eclipse launching mechanism. This would be to have classpath, vm arguments, program arguments and main class available as separate parts.

[~rob.stryker] can you confirm if those are the "split" we need and whether we can actually use processbuilder to launch our own stuff directly in eclipse or must use eclipse native launch mechanism ?
 
                
> Launcher API
> ------------
>
>                 Key: WFLY-2427
>                 URL: https://issues.jboss.org/browse/WFLY-2427
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Ondrej Zizka
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. 
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. 
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -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 "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.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 issues at jboss.org  Tue Jan 21 03:38:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 03:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.3653.1390293508486@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937431#comment-12937431 ] 

RH Bugzilla Integration commented on WFLY-2782:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1055912|https://bugzilla.redhat.com/show_bug.cgi?id=1055912] from NEW to POST
                
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 03:48:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 21 Jan 2014 03:48:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2439) Arquillian Wildfly Managed -
 support exploded mode
In-Reply-To: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518015.1383653230000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518015.1383653230000.3692.1390294109083@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2439.
----------------------------------

    Resolution: Rejected


Adding support for this to arquillian is not the way to do this. Instead have a look at org.jboss.as.test.manualmode.deployment.DeploymentScannerUnitTestCase for an example of how to best test this.

Basically just add a deployment scanner that points to a directory, and assemble an exploded deployment in that directory. 
                
> Arquillian Wildfly Managed - support exploded mode
> --------------------------------------------------
>
>                 Key: WFLY-2439
>                 URL: https://issues.jboss.org/browse/WFLY-2439
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Zizka
>              Labels: arquillian
>
> Arquillian WildFly managed container currently doesn't support exploded mode deployment. JBDS supports it through moving the files to the standalone/deployments dir. It would be nice if we could add some tests covering this to the WildFly testsuite.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 04:46:28 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Tue, 21 Jan 2014 04:46:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2766) .jar's on "current runtime
	classpath"
In-Reply-To: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529603.1389881603000.3854.1390297588966@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937444#comment-12937444 ] 

Max Rydahl Andersen commented on WFLY-2766:
-------------------------------------------

[~rob.stryker] that question is more on the IDE side to solve not wildfly. We would still need to include more than they actually ask for - i.e. the javaee spec api jars would be a basic start, or simply map from eclipse facets to the groupings used in wildfly.

                
> .jar's on "current runtime classpath"
> -------------------------------------
>
>                 Key: WFLY-2766
>                 URL: https://issues.jboss.org/browse/WFLY-2766
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ondrej Zizka
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra)  have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 06:34:28 2014
From: issues at jboss.org (=?UTF-8?Q?Markus_von_R=C3=BCden_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 06:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2783)
 EmbeddedContainerConfiguration does not validate correctly
In-Reply-To: <JIRA.12529972.1390303993779@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529972.1390303993779@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529972.1390303993779.4081.1390304068519@jira02.app.mwc.hst.phx2.redhat.com>

Markus von R?den created WFLY-2783:
--------------------------------------

             Summary: EmbeddedContainerConfiguration does not validate correctly
                 Key: WFLY-2783
                 URL: https://issues.jboss.org/browse/WFLY-2783
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Markus von R?den
            Priority: Minor


I experimented a bit with arquillian and the embedded wildfly container.

However, durinng startup I am getting this exception: 

    java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))


So I took a deeper look at class 
org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"

The validate method there seems to have a validation problem:
@Override
    public void validate() throws ConfigurationException {
        super.validate();
        Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
    }

It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome 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 issues at jboss.org  Tue Jan 21 06:36:28 2014
From: issues at jboss.org (=?UTF-8?Q?Markus_von_R=C3=BCden_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 06:36:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2783)
 EmbeddedContainerConfiguration does not validate correctly
In-Reply-To: <JIRA.12529972.1390303993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529972.1390303993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529972.1390303993000.4083.1390304188614@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Markus von R?den updated WFLY-2783:
-----------------------------------

    Description: 
I experimented a bit with arquillian and the embedded wildfly container.

However, durinng startup I am getting this exception: 

{code}
    java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))
{code}

So I took a deeper look at class 
org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"

The validate method there seems to have a validation problem:
{code}
@Override
    public void validate() throws ConfigurationException {
        super.validate();
        Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
    }
{code}

It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome instead.



  was:
I experimented a bit with arquillian and the embedded wildfly container.

However, durinng startup I am getting this exception: 

    java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))


So I took a deeper look at class 
org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"

The validate method there seems to have a validation problem:
@Override
    public void validate() throws ConfigurationException {
        super.validate();
        Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
    }

It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome instead.




    
> EmbeddedContainerConfiguration does not validate correctly
> ----------------------------------------------------------
>
>                 Key: WFLY-2783
>                 URL: https://issues.jboss.org/browse/WFLY-2783
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Markus von R?den
>            Priority: Minor
>
> I experimented a bit with arquillian and the embedded wildfly container.
> However, durinng startup I am getting this exception: 
> {code}
>     java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))
> {code}
> So I took a deeper look at class 
> org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"
> The validate method there seems to have a validation problem:
> {code}
> @Override
>     public void validate() throws ConfigurationException {
>         super.validate();
>         Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
>         Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
>         Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
>     }
> {code}
> It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome 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 issues at jboss.org  Tue Jan 21 06:36:28 2014
From: issues at jboss.org (=?UTF-8?Q?Markus_von_R=C3=BCden_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 06:36:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2783)
 EmbeddedContainerConfiguration does not validate correctly
In-Reply-To: <JIRA.12529972.1390303993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529972.1390303993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529972.1390303993000.4085.1390304188679@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Markus von R?den updated WFLY-2783:
-----------------------------------

    Description: 
I experimented a bit with arquillian and the embedded wildfly container.

However, durinng startup I am getting this exception: 

{code}
    java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))
{code}

So I took a deeper look at class 
org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"

The validate method there seems to have a validation problem:
{code}
@Override
    public void validate() throws ConfigurationException {
        super.validate();
        Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
    }
{code}

It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome instead.

I am not sure if the Exception and the validation-implementation are associated with each other in any way, but the validate() method looks wrong to me :)



  was:
I experimented a bit with arquillian and the embedded wildfly container.

However, durinng startup I am getting this exception: 

{code}
    java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))
{code}

So I took a deeper look at class 
org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"

The validate method there seems to have a validation problem:
{code}
@Override
    public void validate() throws ConfigurationException {
        super.validate();
        Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
        Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
    }
{code}

It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome instead.




    
> EmbeddedContainerConfiguration does not validate correctly
> ----------------------------------------------------------
>
>                 Key: WFLY-2783
>                 URL: https://issues.jboss.org/browse/WFLY-2783
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Markus von R?den
>            Priority: Minor
>
> I experimented a bit with arquillian and the embedded wildfly container.
> However, durinng startup I am getting this exception: 
> {code}
>     java.lang.RuntimeException: JBAS011137: Cannot load module org.jboss.vfs from: local module loader @3a55b9b (finder: local module finder @5d211efb (roots: /home/username/dev/arquillian-tutorial/null/modules))
> {code}
> So I took a deeper look at class 
> org.jboss.as.arquillian.container.embedded.EmbeddedContainerConfiguration located in "wildfly/arquillian/embedded"
> The validate method there seems to have a validation problem:
> {code}
> @Override
>     public void validate() throws ConfigurationException {
>         super.validate();
>         Validate.configurationDirectoryExists(jbossHome, "jbossHome '" + jbossHome + "' must exist");
>         Validate.configurationDirectoryExists(jbossHome, "modulePath '" + modulePath + "' must exist");
>         Validate.configurationDirectoryExists(jbossHome, "bundlePath '" + bundlePath + "' must exist");
>     }
> {code}
> It checks jbossHome three times. But I assume it should check jbossHome, bundleHome and moduleHome instead.
> I am not sure if the Exception and the validation-implementation are associated with each other in any way, but the validate() method looks wrong to me :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 07:06:28 2014
From: issues at jboss.org (=?UTF-8?Q?Micha=C3=ABl_Mathieu_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 07:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Problem with inheritance
In-Reply-To: <JIRA.12529976.1390305870792@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870792@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870792.4121.1390305988877@jira02.app.mwc.hst.phx2.redhat.com>

Micha?l Mathieu created DROOLS-410:
--------------------------------------

             Summary: Problem with inheritance
                 Key: DROOLS-410
                 URL: https://issues.jboss.org/browse/DROOLS-410
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Micha?l Mathieu
            Assignee: Mark Proctor


For a very simple rule, with same parameter, the result is sometimes different.

There's a problem with inheritance.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{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 issues at jboss.org  Tue Jan 21 07:06:29 2014
From: issues at jboss.org (Rob Stryker (JIRA))
Date: Tue, 21 Jan 2014 07:06:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2766) .jar's on "current runtime
	classpath"
In-Reply-To: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529603.1389881603000.4130.1390305989364@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937481#comment-12937481 ] 

Rob Stryker commented on WFLY-2766:
-----------------------------------

[~maxandersen] If we still need to include more than they ask (specifically all the javaee specs) then what do we gain here? The point of this api was that a given app would receive the jars it requires, via the wildfly api.  If we still need to customize the list, then I fail to see how we gain anything. Maybe I'm missing something here. 
                
> .jar's on "current runtime classpath"
> -------------------------------------
>
>                 Key: WFLY-2766
>                 URL: https://issues.jboss.org/browse/WFLY-2766
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ondrej Zizka
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra)  have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 07:08:29 2014
From: issues at jboss.org (=?UTF-8?Q?Micha=C3=ABl_Mathieu_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 07:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Problem with inheritance
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.4138.1390306109128@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Micha?l Mathieu updated DROOLS-410:
-----------------------------------

    Description: 
For a very simple rule, with same parameter, the result is sometimes different.

There's a problem with inheritance.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{code}

Output:
{code}
package test
dialect "mvel"
import test.*;
rule "myRule"
when
  criteria:Criteria(ref == BRef.valueOf("toto"))
then
  criteria.setOk();
end
BRef> toto
BRef> toto
BRef> toto
[0] true
BRef> toto
BRef> toto
[1] true
BRef> toto
BRef> toto
[2] true
...
[108] false
BRef> toto
ARef> toto
[109] false
BRef> toto
ARef> toto
...
BRef> toto
ARef> toto
[998] false
BRef> toto
ARef> toto
[999] false
{code}

  was:
For a very simple rule, with same parameter, the result is sometimes different.

There's a problem with inheritance.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{code}


    
> Problem with inheritance
> ------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mark Proctor
>
> For a very simple rule, with same parameter, the result is sometimes different.
> There's a problem with inheritance.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> [108] false
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Tue Jan 21 07:08:29 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 21 Jan 2014 07:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2589)
 ReadTransformedResourceOperation should set include-defaults=false when
 calling read-resource
In-Reply-To: <JIRA.12526485.1385660411000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526485.1385660411000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526485.1385660411000.4142.1390306109316@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937483#comment-12937483 ] 

Kabir Khan commented on WFLY-2589:
----------------------------------

I am not sure if this should be done see notes at https://community.jboss.org/wiki/TransformersMini-sessionBrnoJan2014
                
> ReadTransformedResourceOperation should set include-defaults=false when calling read-resource
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2589
>                 URL: https://issues.jboss.org/browse/WFLY-2589
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>
> This needs further investigation, but it seems to mean that we have a lot of ModelFixers used in the wrong situation. i.e. the when transforming resources, attributes that should be undefined reach the transformers as defined with the default value set instead.
> This needs a bit of thinking about [~jmesnil] mentioned this a few weeks ago as well. I'd like to see if he remembers before fixing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 07:10:28 2014
From: issues at jboss.org (=?UTF-8?Q?Micha=C3=ABl_Mathieu_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 07:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Problem with inheritance
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.4145.1390306228757@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Micha?l Mathieu updated DROOLS-410:
-----------------------------------

    Description: 
For a very simple rule, with same parameter, the result is sometimes different.

There's a problem with inheritance.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{code}

Output:
{code}
package test
dialect "mvel"
import test.*;
rule "myRule"
when
  criteria:Criteria(ref == BRef.valueOf("toto"))
then
  criteria.setOk();
end
BRef> toto
BRef> toto
BRef> toto
[0] true
BRef> toto
BRef> toto
[1] true
BRef> toto
BRef> toto
[2] true
...
BRef> toto
ARef> toto
[109] false
BRef> toto
ARef> toto
[110] false
...
BRef> toto
ARef> toto
[998] false
BRef> toto
ARef> toto
[999] false
{code}

  was:
For a very simple rule, with same parameter, the result is sometimes different.

There's a problem with inheritance.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{code}

Output:
{code}
package test
dialect "mvel"
import test.*;
rule "myRule"
when
  criteria:Criteria(ref == BRef.valueOf("toto"))
then
  criteria.setOk();
end
BRef> toto
BRef> toto
BRef> toto
[0] true
BRef> toto
BRef> toto
[1] true
BRef> toto
BRef> toto
[2] true
...
[108] false
BRef> toto
ARef> toto
[109] false
BRef> toto
ARef> toto
...
BRef> toto
ARef> toto
[998] false
BRef> toto
ARef> toto
[999] false
{code}


    
> Problem with inheritance
> ------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mark Proctor
>
> For a very simple rule, with same parameter, the result is sometimes different.
> There's a problem with inheritance.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Tue Jan 21 07:28:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 07:28:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.4179.1390307308681@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2739:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 07:30:28 2014
From: issues at jboss.org (Max Rydahl Andersen (JIRA))
Date: Tue, 21 Jan 2014 07:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2766) .jar's on "current runtime
	classpath"
In-Reply-To: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529603.1389881603000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529603.1389881603000.4186.1390307428661@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937492#comment-12937492 ] 

Max Rydahl Andersen commented on WFLY-2766:
-------------------------------------------

For the compile usecase you with this get the location of jars needed for this that is not overlapping or conflicting.  
                
> .jar's on "current runtime classpath"
> -------------------------------------
>
>                 Key: WFLY-2766
>                 URL: https://issues.jboss.org/browse/WFLY-2766
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Class Loading, CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ondrej Zizka
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR1
>
>
> (Based on JBDS use case - see EAP6-1)
> In certain scenarios, JBDS needs to know the classpath. (Compilation of non-maven project, against a remote server, ...(?) )
> The classpath would be:
> * for the deployment after deployed
> * for a generic deployment if it was deployed right now - what would WildFly use?
> * for the deployment before deployed - sounds a bit advanced but technically possible
> We (David, Stuart, Jason, Max, Ondra)  have discussed this on EAP F2F 2014.
> The output was that we don't need exact classpath / list of jars which would probably end up being almost all modules; rather we need the direct deps. As someone said - "just to get rid of the red lines in the IDE".
> The non-maven compilation use case is that the user has a server in a directory, and the jars to build against should all be in there. So the IDE should be able to ask WildFly for a list of .jar's to build the application against, and just use that instead of forcing the user to gather them manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 07:38:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 21 Jan 2014 07:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.4199.1390307908537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet moved PLANNER-219 to DROOLS-411:
-------------------------------------------------

              Project: Drools  (was: OptaPlanner)
                  Key: DROOLS-411  (was: PLANNER-219)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s: 6.0.1.Final
                           (was: 6.0.1.Final)
          Component/s:     (was: optaplanner-examples)
             Security: Public

    
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Tue Jan 21 07:38:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 21 Jan 2014 07:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.4202.1390307908733@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-411:
------------------------------------

    Assignee: Mario Fusco  (was: Geoffrey De Smet)

    
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Tue Jan 21 07:46:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 07:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.4214.1390308389143@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937498#comment-12937498 ] 

Jozef Hartinger commented on WFLY-2739:
---------------------------------------

The testcase you provided is difficult to work with due to LF/CRLF diffs.
                
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 07:48:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 07:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.4217.1390308508639@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2739:
----------------------------------

    Workaround Description:   (was: exclude already processed beans.xml:
https://github.com/petrandreev/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java#L175-176

pull request can be provided)

    
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 07:50:29 2014
From: issues at jboss.org (=?UTF-8?Q?Micha=C3=ABl_Mathieu_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 07:50:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Drools invokes superclass
	static method
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.4230.1390308629030@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Micha?l Mathieu updated DROOLS-410:
-----------------------------------

        Summary: Drools invokes superclass static method  (was: Problem with inheritance)
    Description: 
For a very simple rule, with same parameter, the result is sometimes different.

Drools invokes superclass static method.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{code}

Output:
{code}
package test
dialect "mvel"
import test.*;
rule "myRule"
when
  criteria:Criteria(ref == BRef.valueOf("toto"))
then
  criteria.setOk();
end
BRef> toto
BRef> toto
BRef> toto
[0] true
BRef> toto
BRef> toto
[1] true
BRef> toto
BRef> toto
[2] true
...
BRef> toto
ARef> toto
[109] false
BRef> toto
ARef> toto
[110] false
...
BRef> toto
ARef> toto
[998] false
BRef> toto
ARef> toto
[999] false
{code}

  was:
For a very simple rule, with same parameter, the result is sometimes different.

There's a problem with inheritance.

{code}
package test;

public class ARef {
    private String ref;

    protected ARef(String ref) {
        this.ref = ref;
    }

    public static ARef valueOf(String ref) {
        System.out.println("ARef> " + ref);
        return new ARef(ref);
    }

    @Override
    public String toString() {
        return ref;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((ref == null) ? 0 : ref.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null) return false;
        if (getClass() != obj.getClass()) return false;
        ARef other = (ARef) obj;
        if (ref == null) {
            if (other.ref != null) return false;
        } else if (!ref.equals(other.ref)) return false;
        return true;
    }
}
{code}

{code}
package test;

public class BRef extends ARef {
    private BRef(String ref) {
        super(ref);
    }

    public static BRef valueOf(String ref) {
        System.out.println("BRef> " + ref);
        return new BRef(ref);
    }
}
{code}

{code}
package test;

public class Criteria {
    private BRef ref;

    private boolean ok = false;

    public Criteria(BRef ref) {
        this.ref = ref;
    }

    public BRef getRef() {
        return ref;
    }

    public boolean isOk() {
        return ok;
    }

    public void setOk() {
        this.ok = true;
    }
}
{code}

{code}
package test;

import java.io.StringReader;

import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatelessSession;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;

public class Test {
    private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
            + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";

    public static void main(String[] args) {
        System.out.println(DRL);
        try {
            PackageBuilder builder = new PackageBuilder();
            builder.addPackageFromDrl(new StringReader(DRL));
            Package pkg = builder.getPackage();
            RuleBase ruleBase = RuleBaseFactory.newRuleBase();
            ruleBase.addPackage(pkg);

            for (int i = 0; i < 1000; i++) {
                Criteria criteria = new Criteria(BRef.valueOf("toto"));

                StatelessSession session = ruleBase.newStatelessSession();
                session.execute(criteria);

                System.out.println("[" + i + "] " + criteria.isOk());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
{code}

Output:
{code}
package test
dialect "mvel"
import test.*;
rule "myRule"
when
  criteria:Criteria(ref == BRef.valueOf("toto"))
then
  criteria.setOk();
end
BRef> toto
BRef> toto
BRef> toto
[0] true
BRef> toto
BRef> toto
[1] true
BRef> toto
BRef> toto
[2] true
...
BRef> toto
ARef> toto
[109] false
BRef> toto
ARef> toto
[110] false
...
BRef> toto
ARef> toto
[998] false
BRef> toto
ARef> toto
[999] false
{code}


    
> Drools invokes superclass static method
> ---------------------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mark Proctor
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Tue Jan 21 07:52:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 07:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.4238.1390308748854@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2739:
----------------------------------

    Workaround Description: 
exclude already processed beans.xml:
https://github.com/petrandreev/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java#L175-176

pull request can be provided

    
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 07:56:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 07:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2719) NullPointerException on first
 request after deployment using beans.xml
In-Reply-To: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528793.1389121287000.4248.1390308988835@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger resolved WFLY-2719.
-----------------------------------

    Resolution: Done

    
> NullPointerException on first request after deployment using beans.xml
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2719
>                 URL: https://issues.jboss.org/browse/WFLY-2719
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: James Bodkin
>            Assignee: Stuart Douglas
>            Priority: Minor
>         Attachments: dew.zip
>
>
> A NullPointerException occurs on the first request to the WildFly AS if the war package already exists and has been deployed via maven on both occasions causing an 500 Internal Server Error on the client.
> Removing the beans.xml from WEB-INF stops the error from occurring but services aren't injected.
> 02:36:11,177 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
> 	at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
> 	at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
> 	at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
> 	at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
> 	at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
> 	at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
> 	at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
> 	at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
> 	at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
> 	at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:46)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.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 issues at jboss.org  Tue Jan 21 07:56:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 07:56:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2719) NullPointerException on first
 request after deployment using beans.xml
In-Reply-To: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528793.1389121287000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528793.1389121287000.4253.1390308989180@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2719:
----------------------------------

    Fix Version/s: 8.0.0.Final

    
> NullPointerException on first request after deployment using beans.xml
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2719
>                 URL: https://issues.jboss.org/browse/WFLY-2719
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: James Bodkin
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>         Attachments: dew.zip
>
>
> A NullPointerException occurs on the first request to the WildFly AS if the war package already exists and has been deployed via maven on both occasions causing an 500 Internal Server Error on the client.
> Removing the beans.xml from WEB-INF stops the error from occurring but services aren't injected.
> 02:36:11,177 ERROR [io.undertow.request] (default I/O-3) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:47)
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getRequestAttribute(HttpConversationContextImpl.java:13)
> 	at org.jboss.weld.context.AbstractConversationContext.copyConversationIdGeneratorAndConversationsToSession(AbstractConversationContext.java:177)
> 	at org.jboss.weld.context.AbstractConversationContext.sessionCreated(AbstractConversationContext.java:185)
> 	at org.jboss.weld.servlet.ConversationContextActivator.sessionCreated(ConversationContextActivator.java:187)
> 	at org.jboss.weld.servlet.HttpContextLifecycle.sessionCreated(HttpContextLifecycle.java:122)
> 	at org.jboss.weld.servlet.WeldInitialListener.sessionCreated(WeldInitialListener.java:107)
> 	at io.undertow.servlet.core.ApplicationListeners.sessionCreated(ApplicationListeners.java:256)
> 	at io.undertow.servlet.core.SessionListenerBridge.sessionCreated(SessionListenerBridge.java:36)
> 	at io.undertow.server.session.SessionListeners.sessionCreated(SessionListeners.java:32)
> 	at io.undertow.server.session.InMemorySessionManager.createSession(InMemorySessionManager.java:121)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> 	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:691)
> 	at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:110)
> 	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:56)
> 	at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> 	at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> 	at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> 	at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:142)
> 	at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:46)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.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 issues at jboss.org  Tue Jan 21 08:40:28 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 21 Jan 2014 08:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2784) MyFaces fails in JSF TCK
In-Reply-To: <JIRA.12529992.1390311600994@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529992.1390311600994@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529992.1390311600994.4384.1390311628647@jira02.app.mwc.hst.phx2.redhat.com>

Tomas Remes created WFLY-2784:
---------------------------------

             Summary: MyFaces fails in JSF TCK
                 Key: WFLY-2784
                 URL: https://issues.jboss.org/browse/WFLY-2784
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: 8.0.0.CR1
            Reporter: Tomas Remes
            Assignee: Farah Juma


I can see one major issue, when running JSF TCK against MyFaces (2.1.14, 2.2.0-beta) configured as default JSF slot in WildFly. The problem is described here https://community.jboss.org/message/853890 - basically ResourceHandlerImpl is not able to create "jsf.js" resource file, which is avaliable in MyFaces api jar. This results to:

{noformat}
Caused by: java.lang.NullPointerException
	at org.apache.myfaces.shared.renderkit.html.util.ResourceUtils.renderDefaultJsfJsInlineIfNecessary(ResourceUtils.java:231) [myfaces-impl-2.1.13.jar:2.1.13]
	at org.apache.myfaces.shared.renderkit.html.HtmlButtonRendererBase.encodeEnd(HtmlButtonRendererBase.java:138) [myfaces-impl-2.1.13.jar:2.1.13]
	at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665) [myfaces-api-2.1.13.jar:2.1.13]
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545) [myfaces-api-2.1.13.jar:2.1.13]
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) [myfaces-api-2.1.13.jar:2.1.13]
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) [myfaces-api-2.1.13.jar:2.1.13]
	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) [myfaces-api-2.1.13.jar:2.1.13]
	at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981) [myfaces-impl-2.1.13.jar:2.1.13]
	at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:305) [myfaces-impl-2.1.13.jar:2.1.13]
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59) [myfaces-api-2.1.13.jar:2.1.13]
	at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116) [myfaces-impl-2.1.13.jar:2.1.13]
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) [myfaces-impl-2.1.13.jar:2.1.13]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) [myfaces-api-2.1.13.jar:2.1.13]
	... 24 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 issues at jboss.org  Tue Jan 21 08:42:28 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 21 Jan 2014 08:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2784) MyFaces fails in JSF TCK
In-Reply-To: <JIRA.12529992.1390311600000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529992.1390311600000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529992.1390311600000.4387.1390311748959@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated WFLY-2784:
------------------------------

    Attachment: jsf_ajax_keyword_web.war

    
> MyFaces fails in JSF TCK
> ------------------------
>
>                 Key: WFLY-2784
>                 URL: https://issues.jboss.org/browse/WFLY-2784
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Farah Juma
>         Attachments: jsf_ajax_keyword_web.war
>
>
> I can see one major issue, when running JSF TCK against MyFaces (2.1.14, 2.2.0-beta) configured as default JSF slot in WildFly. The problem is described here https://community.jboss.org/message/853890 - basically ResourceHandlerImpl is not able to create "jsf.js" resource file, which is avaliable in MyFaces api jar. This results to:
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at org.apache.myfaces.shared.renderkit.html.util.ResourceUtils.renderDefaultJsfJsInlineIfNecessary(ResourceUtils.java:231) [myfaces-impl-2.1.13.jar:2.1.13]
> 	at org.apache.myfaces.shared.renderkit.html.HtmlButtonRendererBase.encodeEnd(HtmlButtonRendererBase.java:138) [myfaces-impl-2.1.13.jar:2.1.13]
> 	at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:665) [myfaces-api-2.1.13.jar:2.1.13]
> 	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:545) [myfaces-api-2.1.13.jar:2.1.13]
> 	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) [myfaces-api-2.1.13.jar:2.1.13]
> 	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) [myfaces-api-2.1.13.jar:2.1.13]
> 	at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) [myfaces-api-2.1.13.jar:2.1.13]
> 	at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981) [myfaces-impl-2.1.13.jar:2.1.13]
> 	at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:305) [myfaces-impl-2.1.13.jar:2.1.13]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59) [myfaces-api-2.1.13.jar:2.1.13]
> 	at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116) [myfaces-impl-2.1.13.jar:2.1.13]
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) [myfaces-impl-2.1.13.jar:2.1.13]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) [myfaces-api-2.1.13.jar:2.1.13]
> 	... 24 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 issues at jboss.org  Tue Jan 21 09:58:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 21 Jan 2014 09:58:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-457) Replace mod_cluster proxy-list
 attribute with list of outbound socket bindings
In-Reply-To: <JIRA.12489843.1366309174000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489843.1366309174000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489843.1366309174000.4605.1390316309339@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-457:
--------------------------------

           Issue Type: Feature Request  (was: Task)
      Bugzilla Update:   (was: Perform)
             Priority: Critical  (was: Major)
    Affects Version/s: 8.0.0.Final


There is actually another problem, that the default interface is always used and it is impossible at the moment to configure it (after rework, it can be set via source-interface attribute on outbound-socket-binding).
                
> Replace mod_cluster proxy-list attribute with list of outbound socket bindings
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-457
>                 URL: https://issues.jboss.org/browse/WFLY-457
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 9.0.0.CR1
>
>
> Currently, the mod_cluster subsystem defines proxies using a comma separated string of address:port.  This attribute needs to be deprecated in favor of an attribute, call it "proxies" that defines an xs:list of outbound socket binding 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 issues at jboss.org  Tue Jan 21 10:50:29 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Tue, 21 Jan 2014 10:50:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.4960.1390319429033@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937595#comment-12937595 ] 

Pedro Igor commented on WFLY-2739:
----------------------------------

I think WFLY-2761 fixed this issue too.
                
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>              Labels: jboss
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 10:58:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 10:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2763) Limit Weld packages exported
 to deployments
In-Reply-To: <JIRA.12529577.1389868153000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529577.1389868153000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529577.1389868153000.4999.1390319908653@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger resolved WFLY-2763.
-----------------------------------

    Fix Version/s:     (was: 8.0.0.Final)
       Resolution: Rejected


There are too may internal dependencies currently.
                
> Limit Weld packages exported to deployments
> -------------------------------------------
>
>                 Key: WFLY-2763
>                 URL: https://issues.jboss.org/browse/WFLY-2763
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 11:10:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Jan 2014 11:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1774) Avoid buffer allocations when
 encoding a long for appending to another buffer
In-Reply-To: <JIRA.12529729.1389999342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529729.1389999342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529729.1389999342000.5008.1390320628891@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937601#comment-12937601 ] 

Bela Ban commented on JGRP-1774:
--------------------------------

Moved methods read/writeLong(), read/writeLongSequence() and size() from Util to Bits 
                
> Avoid buffer allocations when encoding a long for appending to another buffer
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1774
>                 URL: https://issues.jboss.org/browse/JGRP-1774
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 3.5
>
>
> When a long gets encoded, a function is used which returns a {{byte[]}}.
> There are some hot methods which invoke this encoding, to then append the buffer's content into a _DataOutput_. Especially for the case of these hot methods we should rather have the function write the encoded form directly into the _DataOutput_.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 11:12:28 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Tue, 21 Jan 2014 11:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.5013.1390320748686@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937604#comment-12937604 ] 

Pedro Igor commented on WFLY-2689:
----------------------------------

Hi Josef,

     Yes they are all working now ! Thank you very much  !

     Without your changes the following test case is not working:

         https://github.com/pedroigor/wildfly/blob/pl-extension/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/picketlink/core/PartitionManagerProducerTestCase.java

     I'm still writing some more tests, but I think this fix will help them as well.

     This was an important piece to get some more PL features into WildFly.]

Thanks.
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Jozef Hartinger
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 11:22:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 21 Jan 2014 11:22:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Exception thrown,
 when you try to clean server
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.5034.1390321348931@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937610#comment-12937610 ] 

Tomaz Cerar commented on WFLY-2729:
-----------------------------------

[~maxandersen] no such issue yet, but you are welcome to create one in Undertow jira.
This should be better in recent nightly builds, but not perfect yet :)
                
> Exception thrown, when you try to clean server
> ----------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Tue Jan 21 11:32:28 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 21 Jan 2014 11:32:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.5068.1390321948750@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937618#comment-12937618 ] 

Jozef Hartinger commented on WFLY-2689:
---------------------------------------

Note that the @Producer will always only be picked up from a top-level deployment unit (e.g. a war or ear/lib), not from subdeployments.
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Jozef Hartinger
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 11:36:28 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Tue, 21 Jan 2014 11:36:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2689) @Producer method never called
 when producing a bean from a static module
In-Reply-To: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528426.1388061121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528426.1388061121000.5075.1390322188741@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937619#comment-12937619 ] 

Pedro Igor commented on WFLY-2689:
----------------------------------

That should be fine for most of our use cases.
                
> @Producer method never called when producing a bean from a static module
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2689
>                 URL: https://issues.jboss.org/browse/WFLY-2689
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: WildFly 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Jozef Hartinger
>
> I've configured a static module for PicketLink CDI library. This library provides some extensions which are loaded fine, as described by WFLY-1370.
> However, I'm trying to deploy my application which the following producer method:
> {code}
> @Produces
> @PicketLink
> public PartitionManager getPartitionManager() {
>     // produce an instance
> }
> {code}
> Where the @PicketLink annotation is a qualifier that allows my deployment to provide its own instance instead.
> In the PicketLink side, we have a injection point as follows:
> @Inject
> @PicketLink
> private Instance<PartitionManager> partitionManagerInstance;
> Where a call to partitionManagerInstance.isUnsatisfied() always returns true, even if my deployment provides a proper producer method.
> The issue here is that the producer method is never called, despite the use of qualifiers or not.
> FYI, I'm able to listen for events fired by PicketLink during the application startup as follows:
> public void observeIdentityConfigurationEvent(@Observes IdentityConfigurationEvent event) {
>     // observer
> }
> Where IdentityConfigurationEvent is one of the lifecycle events fired by PicketLink during the startup.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 12:44:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 12:44:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2760) Intermittent failure of
 ExternalContextBindingTestCase
In-Reply-To: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529570.1389865466000.5417.1390326268652@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937651#comment-12937651 ] 

RH Bugzilla Integration commented on WFLY-2760:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1054106|https://bugzilla.redhat.com/show_bug.cgi?id=1054106] from ASSIGNED to POST
                
>  Intermittent failure of ExternalContextBindingTestCase
> -------------------------------------------------------
>
>                 Key: WFLY-2760
>                 URL: https://issues.jboss.org/browse/WFLY-2760
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Minor
>
> The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.
> It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 12:54:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 12:54:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2773) ClientConfigurationImpl
 should not translate IP address to host name
In-Reply-To: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529691.1389963183000.5426.1390326868645@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2773:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1054776

    
> ClientConfigurationImpl should not translate IP address to host name
> --------------------------------------------------------------------
>
>                 Key: WFLY-2773
>                 URL: https://issues.jboss.org/browse/WFLY-2773
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> When creating a ModelControllerClient and passing in an IP address, ClientConfigurationImpl internally translates it to a host name, like here:
> {noformat}
> public static ModelControllerClientConfiguration create(final InetAddress address, final int port) {
>         return new ClientConfigurationImpl(address.getHostName(), port, null, null, null, createDefaultExecutor(), true, null);
>     }
> {noformat}
> Later on, when the client connects, it is translated via DNS back to an IP address. This is not only unnecessary, but in some situations, it is wrong.
> Consider a Windows machine having two IP addresses ,A and B, on one network interface, where only A is pointed at by a DNS record. 
> - Run AS testsuite and pass it the address B as the node0 property, AS will bind itself to this address.
> - Now when a test creates a ModelControllerClient using IP address B, the address B will get translated to the host name, even though B is not in the DNS. The resolving works this way on a Windows machine.
> - During the connection, the host name will get resolved by DNS to address A and the test will try to connect through address A. The connection will be refused, or worse, might connect to another instance on the same machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 12:54:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 12:54:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2773) ClientConfigurationImpl
 should not translate IP address to host name
In-Reply-To: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529691.1389963183000.5428.1390326868754@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937654#comment-12937654 ] 

RH Bugzilla Integration commented on WFLY-2773:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1054776|https://bugzilla.redhat.com/show_bug.cgi?id=1054776] from ASSIGNED to POST
                
> ClientConfigurationImpl should not translate IP address to host name
> --------------------------------------------------------------------
>
>                 Key: WFLY-2773
>                 URL: https://issues.jboss.org/browse/WFLY-2773
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> When creating a ModelControllerClient and passing in an IP address, ClientConfigurationImpl internally translates it to a host name, like here:
> {noformat}
> public static ModelControllerClientConfiguration create(final InetAddress address, final int port) {
>         return new ClientConfigurationImpl(address.getHostName(), port, null, null, null, createDefaultExecutor(), true, null);
>     }
> {noformat}
> Later on, when the client connects, it is translated via DNS back to an IP address. This is not only unnecessary, but in some situations, it is wrong.
> Consider a Windows machine having two IP addresses ,A and B, on one network interface, where only A is pointed at by a DNS record. 
> - Run AS testsuite and pass it the address B as the node0 property, AS will bind itself to this address.
> - Now when a test creates a ModelControllerClient using IP address B, the address B will get translated to the host name, even though B is not in the DNS. The resolving works this way on a Windows machine.
> - During the connection, the host name will get resolved by DNS to address A and the test will try to connect through address A. The connection will be refused, or worse, might connect to another instance on the same machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 13:50:28 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 21 Jan 2014 13:50:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-412) NotSerializableException
 when running drools with engine.policy and kie.policy
In-Reply-To: <JIRA.12530032.1390330181144@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530032.1390330181144@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530032.1390330181144.5465.1390330228893@jira02.app.mwc.hst.phx2.redhat.com>

Geoffrey De Smet created DROOLS-412:
---------------------------------------

             Summary: NotSerializableException when running drools with engine.policy and kie.policy
                 Key: DROOLS-412
                 URL: https://issues.jboss.org/browse/DROOLS-412
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Geoffrey De Smet
            Assignee: Edson Tirelli


{code}
Exception in thread "main" org.optaplanner.benchmark.api.PlannerBenchmarkException: Benchmarking failed: failureCount (1). The exception of the firstFailureSingleBenchmarkRunner (comp01_FIRST_FIT_DECREASING) is chained.
	at org.optaplanner.benchmark.impl.PlannerBenchmarkRunner.benchmarkingEnded(PlannerBenchmarkRunner.java:204)
	at org.optaplanner.benchmark.impl.PlannerBenchmarkRunner.benchmark(PlannerBenchmarkRunner.java:86)
	at org.optaplanner.examples.common.app.CommonBenchmarkApp.buildAndBenchmark(CommonBenchmarkApp.java:29)
	at org.optaplanner.examples.curriculumcourse.app.CurriculumCourseBenchmarkApp.main(CurriculumCourseBenchmarkApp.java:47)
	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.RuntimeException: java.io.NotSerializableException: org.drools.core.spi.ReturnValueExpression$SafeReturnValueExpression
	at org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:460)
	at org.drools.core.rule.Package.deepCloneIfAlreadyInUse(Package.java:723)
	at org.drools.core.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:565)
	at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:153)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:318)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieBase(KieContainerImpl.java:277)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieBase(KieContainerImpl.java:272)
	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildKieBase(ScoreDirectorFactoryConfig.java:340)
	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryConfig.java:282)
	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:187)
	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:175)
	at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:145)
	at org.optaplanner.benchmark.impl.SingleBenchmarkRunner.call(SingleBenchmarkRunner.java:72)
	at org.optaplanner.benchmark.impl.SingleBenchmarkRunner.call(SingleBenchmarkRunner.java:32)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	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:724)
Caused by: java.io.NotSerializableException: org.drools.core.spi.ReturnValueExpression$SafeReturnValueExpression
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1181)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.writeExternal(JavaAccumulatorFunctionExecutor.java:71)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.Accumulate.writeExternal(Accumulate.java:106)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.Pattern.writeExternal(Pattern.java:146)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at java.util.ArrayList.writeObject(ArrayList.java:710)
	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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.GroupElement.writeExternal(GroupElement.java:70)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.Rule.writeExternal(Rule.java:150)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.JavaDialectRuntimeData.writeExternal(JavaDialectRuntimeData.java:135)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at java.util.HashMap.writeObject(HashMap.java:1100)
	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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.DialectRuntimeRegistry.writeExternal(DialectRuntimeRegistry.java:45)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.rule.Package.writeExternal(Package.java:181)
	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
	at org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:454)
	... 18 more
{code}

To reproduce:

{code}
Config this run configuration after cloning optaplanner:
Main class: org.optaplanner.examples.curriculumcourse.app.CurriculumCourseBenchmarkApp
Vm options: -Xmx1536M -server -Djava.security.manager -Djava.security.policy=/home/gdesmet/tmp/support/edson/security/engine.policy -Dkie.security.policy=/home/gdesmet/tmp/support/edson/security/kie.policy
working dir: $MODULE_DIR$ (optaplanner-examples)
{code}


Weird is that it didn't happen on all datasets. Looks like only on the once where the KieSession was created 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 issues at jboss.org  Tue Jan 21 14:42:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 14:42:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-130) Cygwin,
 add-user.sh and error "JBAS015232: Aucune java.io.Console
 disponible pour interagir avec l'utilisateur."
In-Reply-To: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483614.1359396502000.5581.1390333349131@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937680#comment-12937680 ] 

Aleksandar Kostadinov commented on WFLY-130:
--------------------------------------------

I've created a PR for the wrong bash syntax with cygwin=true (https://github.com/wildfly/wildfly/pull/5737#issuecomment-32890105)

The other problem is also still present. I'm pasting the english version of the exception here. It is IMO in the aesh component:{CODE}
Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
	at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:79)
	at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:237)
	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)
{CODE}

btw a workaround would be to use the -s option and provide necessary parameters to the command such that user input is not required. Sometimes inconvenient but at least somehow works.
                
> Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-130
>                 URL: https://issues.jboss.org/browse/WFLY-130
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>         Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
>            Reporter: Bernard Giroud
>            Assignee: Darran Lofthouse
>              Labels: as7, management
>             Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
>     cygwin = true;
> {code}
> It should read:
> {code}
>     cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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 issues at jboss.org  Tue Jan 21 14:42:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 14:42:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-130) Cygwin,
 add-user.sh and error "JBAS015232: Aucune java.io.Console
 disponible pour interagir avec l'utilisateur."
In-Reply-To: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483614.1359396502000.5586.1390333349403@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937680#comment-12937680 ] 

Aleksandar Kostadinov edited comment on WFLY-130 at 1/21/14 2:42 PM:
---------------------------------------------------------------------

I've created a PR for the wrong bash syntax with cygwin=true (https://github.com/wildfly/wildfly/pull/5737)

The other problem is also still present. I'm pasting the english version of the exception here. It is IMO in the aesh component:{CODE}
Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
	at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:79)
	at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:237)
	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)
{CODE}

btw a workaround would be to use the -s option and provide necessary parameters to the command such that user input is not required. Sometimes inconvenient but at least somehow works.
                
      was (Author: akostadinov):
    I've created a PR for the wrong bash syntax with cygwin=true (https://github.com/wildfly/wildfly/pull/5737#issuecomment-32890105)

The other problem is also still present. I'm pasting the english version of the exception here. It is IMO in the aesh component:{CODE}
Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
	at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:79)
	at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:237)
	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)
{CODE}

btw a workaround would be to use the -s option and provide necessary parameters to the command such that user input is not required. Sometimes inconvenient but at least somehow works.
                  
> Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur."
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-130
>                 URL: https://issues.jboss.org/browse/WFLY-130
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>         Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
>            Reporter: Bernard Giroud
>            Assignee: Darran Lofthouse
>              Labels: as7, management
>             Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
>     cygwin = true;
> {code}
> It should read:
> {code}
>     cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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 issues at jboss.org  Tue Jan 21 14:46:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 14:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-130) Cygwin,
 add-user.sh and error "JBAS015232: No java.io.Console available to
 interact with user."
In-Reply-To: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483614.1359396502000.5609.1390333589582@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-130:
---------------------------------------

              Summary: Cygwin, add-user.sh and error "JBAS015232:  No java.io.Console available to interact with user."  (was: Cygwin, add-user.sh and error "JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.")
             Assignee: Alexey Loubyansky  (was: Darran Lofthouse)
    Affects Version/s: 8.0.0.CR1
          Component/s: CLI
                           (was: Domain Management)
                           (was: Security)

    
> Cygwin, add-user.sh and error "JBAS015232:  No java.io.Console available to interact with user."
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-130
>                 URL: https://issues.jboss.org/browse/WFLY-130
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
>            Reporter: Bernard Giroud
>            Assignee: Alexey Loubyansky
>              Labels: as7, management
>             Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
>     cygwin = true;
> {code}
> It should read:
> {code}
>     cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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 issues at jboss.org  Tue Jan 21 14:46:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 14:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-130) Cygwin,
 add-user.sh and error "JBAS015232: No java.io.Console available to
 interact with user."
In-Reply-To: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483614.1359396502000.5613.1390333589777@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-130:
---------------------------------------

       Assignee: Darran Lofthouse  (was: Alexey Loubyansky)
    Component/s: Domain Management
                 Security
                     (was: CLI)

    
> Cygwin, add-user.sh and error "JBAS015232:  No java.io.Console available to interact with user."
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-130
>                 URL: https://issues.jboss.org/browse/WFLY-130
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
>            Reporter: Bernard Giroud
>            Assignee: Darran Lofthouse
>              Labels: as7, management
>             Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
>     cygwin = true;
> {code}
> It should read:
> {code}
>     cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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 issues at jboss.org  Tue Jan 21 14:48:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 14:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-130) Cygwin,
 add-user.sh and error "JBAS015232: No java.io.Console available to
 interact with user."
In-Reply-To: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483614.1359396502000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483614.1359396502000.5622.1390333708829@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937680#comment-12937680 ] 

Aleksandar Kostadinov edited comment on WFLY-130 at 1/21/14 2:46 PM:
---------------------------------------------------------------------

I've created a PR for the wrong bash syntax with cygwin=true (https://github.com/wildfly/wildfly/pull/5737)

The other problem is also still present. I'm pasting the english version of the exception here:{CODE}
Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
	at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:79)
	at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:237)
	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)
{CODE}

btw a workaround would be to use the -s option and provide necessary parameters to the command such that user input is not required. Sometimes inconvenient but at least somehow works.
                
      was (Author: akostadinov):
    I've created a PR for the wrong bash syntax with cygwin=true (https://github.com/wildfly/wildfly/pull/5737)

The other problem is also still present. I'm pasting the english version of the exception here. It is IMO in the aesh component:{CODE}
Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
	at org.jboss.as.domain.management.security.adduser.AddUser.<init>(AddUser.java:79)
	at org.jboss.as.domain.management.security.adduser.AddUser.main(AddUser.java:237)
	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)
{CODE}

btw a workaround would be to use the -s option and provide necessary parameters to the command such that user input is not required. Sometimes inconvenient but at least somehow works.
                  
> Cygwin, add-user.sh and error "JBAS015232:  No java.io.Console available to interact with user."
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-130
>                 URL: https://issues.jboss.org/browse/WFLY-130
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows XP with CYGWIN_NT-5.1 ... 1.7.17 (0.262/5/3) 2012-10-19 i686
> Java HotSpot 1.7.0_11, RE build 1.7.0_11-b21, Client VM build 23.6-b04, mixed mode
> JBoss AS 7.1.3.Final
>            Reporter: Bernard Giroud
>            Assignee: Darran Lofthouse
>              Labels: as7, management
>             Fix For: 9.0.0.CR1
>
>
> First of all, the add-user.sh script has an invalid syntax on line 14 which reads:
> {code}
>     cygwin = true;
> {code}
> It should read:
> {code}
>     cygwin=true;
> {code}
> without spaces around the equal sign, Otherwise the truth value is not set, and the conversion back to Windows pathes is not done.
> Furthermore, the back-conversions should be conditioned to avoid a "cygpath: can't convert empty path" in lines 56-60, especially with JAVA_HOME.
> Finally, issuance of the following command : bin/add-user.sh u p
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:107)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:118)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:166)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Issuance of the following command : bin/add-user.sh
> Gives:
> {noformat}
> cygpath: can't convert empty path
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: Aucune java.io.Console disponible pour interagir avec l'utilisateur.
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:78)
> 	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:168)
> 	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 org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:294)
> {noformat}
> Option --silent doesn't make a difference.
> An obvious workaround exists though: use with a CMD windows
> {noformat}
> bin\add-user.bat u p
> {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 issues at jboss.org  Tue Jan 21 14:54:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 14:54:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-908) Issue in Interactive mode on
 cygwin not working.
In-Reply-To: <JIRA.12468584.1339451572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12468584.1339451572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468584.1339451572000.5644.1390334068786@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-908:
---------------------------------------

          Description: After connecting to standalone server on localhost, Cgywin doesn't response to input.  (was: 
After connecting to standalone server on localhost, Cgywin doesn't response to input.)
    Affects Version/s: 8.0.0.CR1
          Environment: Windows 7, windows2k8, Cygwin 1.7.15  (was: Windows 7, Cygwin 1.7.15)


FYI this still affects current wildfly nightly.
                
> Issue in Interactive mode on cygwin not working.
> ------------------------------------------------
>
>                 Key: WFLY-908
>                 URL: https://issues.jboss.org/browse/WFLY-908
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows 7, windows2k8, Cygwin 1.7.15
>            Reporter: Peter Cadman
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> After connecting to standalone server on localhost, Cgywin doesn't response to input.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 15:50:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 15:50:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395364@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395364@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395364.5667.1390337428754@jira02.app.mwc.hst.phx2.redhat.com>

Aleksandar Kostadinov created WFLY-2785:
-------------------------------------------

             Summary: master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
                 Key: WFLY-2785
                 URL: https://issues.jboss.org/browse/WFLY-2785
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Server
    Affects Versions: 8.0.0.CR1
         Environment: windows
            Reporter: Aleksandar Kostadinov
            Assignee: Jason Greene


When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).

Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.

Here is how to reproduce:
# on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
# launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
# issue this cli command: reload --restart-servers=false --host=master
# see logs for messages from server-one and server-two (I'll attach an archive with such logs)

The fix I found for the issue is:{CODE}
diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
index 308df0e..c6a88e8 100644
--- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
+++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
@@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
 
 import java.io.IOException;
 import java.io.OutputStream;
-import java.net.InetAddress;
 import java.net.InetSocketAddress;
 import java.util.Collections;
 import java.util.LinkedHashMap;
@@ -769,7 +768,7 @@ class ManagedServer {
         public boolean execute(ManagedServer server) throws Exception {
             assert Thread.holdsLock(ManagedServer.this); // Call under lock
             // Reconnect
-            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
+            final String hostName = managementSocket.getHostString();
             final int port = managementSocket.getPort();
             processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
             return true;
{CODE}

I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?

Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs. This line would even override user selection of hostname, to reverse resolve IP potentially to another hostname if proper reverse entry is missing.
IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 16:00:29 2014
From: issues at jboss.org (Rebecca Biller (JIRA))
Date: Tue, 21 Jan 2014 16:00:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-413) Help content for this
 Eclipse plugin version appears missing
In-Reply-To: <JIRA.12530044.1390337964627@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530044.1390337964627@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530044.1390337964627.5682.1390338029237@jira02.app.mwc.hst.phx2.redhat.com>

Rebecca Biller created DROOLS-413:
-------------------------------------

             Summary: Help content for this Eclipse plugin version appears missing
                 Key: DROOLS-413
                 URL: https://issues.jboss.org/browse/DROOLS-413
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
         Environment: Windows 7, Eclipse Juno, JDK 1.6
            Reporter: Rebecca Biller
            Assignee: Mark Proctor


Our software was previously on Drools 3.3 and we upgraded to Drools 5.5. It is close to completion of testing, and QA has found that the online help doesn't work for Drools as it did with the previous Eclipse plugin. It seems the Drools plugin help folder is empty. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 16:02:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 16:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.5685.1390338148778@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------

    Attachment: server_logs.zip

    
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Jason Greene
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs. This line would even override user selection of hostname, to reverse resolve IP potentially to another hostname if proper reverse entry is missing.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 16:02:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 21 Jan 2014 16:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.5689.1390338148992@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------

    Description: 
When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).

Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.

Here is how to reproduce:
# on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
# launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
# issue this cli command: reload --restart-servers=false --host=master
# see logs for messages from server-one and server-two (I'll attach an archive with such logs)

The fix I found for the issue is:{CODE}
diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
index 308df0e..c6a88e8 100644
--- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
+++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
@@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
 
 import java.io.IOException;
 import java.io.OutputStream;
-import java.net.InetAddress;
 import java.net.InetSocketAddress;
 import java.util.Collections;
 import java.util.LinkedHashMap;
@@ -769,7 +768,7 @@ class ManagedServer {
         public boolean execute(ManagedServer server) throws Exception {
             assert Thread.holdsLock(ManagedServer.this); // Call under lock
             // Reconnect
-            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
+            final String hostName = managementSocket.getHostString();
             final int port = managementSocket.getPort();
             processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
             return true;
{CODE}

I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?

Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.

IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

  was:
When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).

Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.

Here is how to reproduce:
# on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
# launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
# issue this cli command: reload --restart-servers=false --host=master
# see logs for messages from server-one and server-two (I'll attach an archive with such logs)

The fix I found for the issue is:{CODE}
diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
index 308df0e..c6a88e8 100644
--- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
+++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
@@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
 
 import java.io.IOException;
 import java.io.OutputStream;
-import java.net.InetAddress;
 import java.net.InetSocketAddress;
 import java.util.Collections;
 import java.util.LinkedHashMap;
@@ -769,7 +768,7 @@ class ManagedServer {
         public boolean execute(ManagedServer server) throws Exception {
             assert Thread.holdsLock(ManagedServer.this); // Call under lock
             // Reconnect
-            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
+            final String hostName = managementSocket.getHostString();
             final int port = managementSocket.getPort();
             processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
             return true;
{CODE}

I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?

Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs. This line would even override user selection of hostname, to reverse resolve IP potentially to another hostname if proper reverse entry is missing.
IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.



want to run a few tests before I file a PR
                
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Jason Greene
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 16:24:29 2014
From: issues at jboss.org (=?UTF-8?Q?St=C3=A5le_Pedersen_=28JIRA=29?=)
Date: Tue, 21 Jan 2014 16:24:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-908) Issue in Interactive mode on
 cygwin not working.
In-Reply-To: <JIRA.12468584.1339451572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12468584.1339451572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468584.1339451572000.5713.1390339469023@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937701#comment-12937701 ] 

St?le Pedersen commented on WFLY-908:
-------------------------------------

yes, ?sh need a way to check if it is running in a cygwin shell. currently it doesnt do that that and assumes that it is in windows cmd.
                
> Issue in Interactive mode on cygwin not working.
> ------------------------------------------------
>
>                 Key: WFLY-908
>                 URL: https://issues.jboss.org/browse/WFLY-908
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>         Environment: Windows 7, windows2k8, Cygwin 1.7.15
>            Reporter: Peter Cadman
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> After connecting to standalone server on localhost, Cgywin doesn't response to input.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 21 16:42:28 2014
From: issues at jboss.org (Claudio Miranda (JIRA))
Date: Tue, 21 Jan 2014 16:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.5755.1390340548664@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937705#comment-12937705 ] 

Claudio Miranda commented on WFLY-2265:
---------------------------------------

Hi, I tested the following code in WF 8.0.0.Final (cloned from repo on 2014-01-21), and it works, see

    @WebServlet(value="/get")  
    public class GetPath extends HttpServlet {  
      
        @Override  
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {  
            OutputStreamWriter os = new OutputStreamWriter(resp.getOutputStream());  
            os.write("<html><body>");  
            ServletContext sc = getServletContext();  
              
            String file1 = sc.getRealPath("/");  
            print(os, "sc root file path: " + file1);  
              
            file1 = sc.getRealPath("dir/file.txt");  
            print(os, "sc file path: " + file1);  
              
            file1 = req.getRealPath("dir/file.txt");  
            print(os, "req file path: " + file1);  
      
            InputStream is = sc.getResourceAsStream("/dir/file.txt");  
            BufferedReader br = new BufferedReader(new InputStreamReader(is));  
            String line = null;  
            print(os, "===> dentro do arquivo");  
            while ( (line = br.readLine()) != null) {  
                print(os, line);  
            }  
              
            os.write("</body></html>");  
            os.flush();  
            os.close();  
        }  
          
          
        public void print(OutputStreamWriter out, String m) throws IOException {  
            out.write("<p>" + m + "</p>");  
        }  

Accessing the url at /getpath/get just works and returns the path and file content.

Zhihong, can you try with the latest WF 8.0.0.Final ?
                
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Tomaz Cerar
>              Labels: jboss
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 17:16:30 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 21 Jan 2014 17:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.5781.1390342590107@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2265.
-------------------------------

    Resolution: Done


Thank you [~claudio_miranda] for verifying this
                
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Tomaz Cerar
>              Labels: jboss
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 17:34:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 17:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2446) invalid value for
 backup-group-name when it is undefined
In-Reply-To: <JIRA.12518117.1383736727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518117.1383736727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518117.1383736727000.5801.1390343668868@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937713#comment-12937713 ] 

RH Bugzilla Integration commented on WFLY-2446:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1027384|https://bugzilla.redhat.com/show_bug.cgi?id=1027384] from POST to MODIFIED
                
> invalid value for backup-group-name when it is undefined
> --------------------------------------------------------
>
>                 Key: WFLY-2446
>                 URL: https://issues.jboss.org/browse/WFLY-2446
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> In the messaging configuration, the backup-group-node modelNode is passed directly to the HornetQ configuration without checking whether it is defined.
> If it is not undefined, the hornetq configuration will use the "undefined" string as the backup group name instead of returning 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 issues at jboss.org  Tue Jan 21 17:34:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 17:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2499) JMSBridge FailureHandler does
 not load from specified module
In-Reply-To: <JIRA.12524963.1384336124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524963.1384336124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524963.1384336124000.5807.1390343669107@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937715#comment-12937715 ] 

RH Bugzilla Integration commented on WFLY-2499:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1029836|https://bugzilla.redhat.com/show_bug.cgi?id=1029836] from POST to MODIFIED
                
> JMSBridge FailureHandler does not load from specified module
> ------------------------------------------------------------
>
>                 Key: WFLY-2499
>                 URL: https://issues.jboss.org/browse/WFLY-2499
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> If an error occurs and the JMS bridge tries to reconnect to the JMS provider to look up the JMS resources from its FailureHandler, it fails with the exception:
> Stack trace:
> {noformat}
> 10:37:02,546 INFO  [org.hornetq.jms.server] (pool-3-thread-3) HQ121000: Failed to set up JMS bridge connections. Most probably the source or target servers are unavailable. Will retry after a pause of 1,000 ms
> 10:37:03,547 WARN  [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.apache.qpid.jndi.PropertiesFileInitialContextFactory from classloader ModuleClassLoader for Module "org.hornetq:main" from local module loader @ac44b88 (finder: local module finder @5d3ad33d (roots: /usr/share/jbossas/modules,/usr/share/jbossas/modules/system/layers/base))
>     at org.jboss.as.naming.InitialContextFactoryBuilder.createInitialContextFactory(InitialContextFactoryBuilder.java:64)
>     at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:681) [rt.jar:1.6.0_24]
>     at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305) [rt.jar:1.6.0_24]
>     at javax.naming.InitialContext.init(InitialContext.java:240) [rt.jar:1.6.0_24]
>     at javax.naming.InitialContext.<init>(InitialContext.java:214) [rt.jar:1.6.0_24]
>     at org.hornetq.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:55) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:40) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1222) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1460) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$2000(JMSBridgeImpl.java:83) [hornetq-jms-server.jar:]
>     at org.hornetq.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:2049) [hornetq-jms-server.jar:]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
>     at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
> {noformat}
> The issue is that the ExecutorService executing the FailureHandler is created when the JMSBridge is instantiated and will not use the ClassLoader from the specified module that gives access to the JMS provider's classes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 18:16:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Jan 2014 18:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-153) Fix logging of "Standard
 expiration of session X failed;
 switching to a brute force cleanup. Problem is null"
In-Reply-To: <JIRA.12467646.1338383878000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467646.1338383878000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467646.1338383878000.5846.1390346189499@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937723#comment-12937723 ] 

RH Bugzilla Integration commented on WFLY-153:
----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 900552|https://bugzilla.redhat.com/show_bug.cgi?id=900552] from POST to MODIFIED
                
> Fix logging of "Standard expiration of session X failed; switching to a brute force cleanup. Problem is null"
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-153
>                 URL: https://issues.jboss.org/browse/WFLY-153
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha2
>
>
> I am seeing exception with missing reason
> {noformat}
> 19:54:12,862 WARN  [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018080: Standard expiration of session 7TYWbrkMf6UGi4WUu2Z3VUam failed; switching to a brute force cleanup. Problem is null
> {noformat}
> Looks like the actual exception is not well propagated to the message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 18:18:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 21 Jan 2014 18:18:28 -0500 (EST)
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.5851.1390346308558@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937724#comment-12937724 ] 

Tomaz Cerar commented on WFLY-1801:
-----------------------------------

Current WIP https://github.com/wildfly/wildfly/pull/5743
                
> Allow remoting endpoint options to be configurable
> --------------------------------------------------
>
>                 Key: WFLY-1801
>                 URL: https://issues.jboss.org/browse/WFLY-1801
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>            Reporter: jaikiran pai
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 21 21:06:28 2014
From: issues at jboss.org (Claudio Miranda (JIRA))
Date: Tue, 21 Jan 2014 21:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-771) JBoss AS 7 documentation
 cannot be exported to PDF
In-Reply-To: <JIRA.12464006.1334337487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464006.1334337487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464006.1334337487000.5919.1390356388565@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937733#comment-12937733 ] 

Claudio Miranda commented on WFLY-771:
--------------------------------------

The wiki at [1] is able to export to PDF see attached images.

1. https://docs.jboss.org/author/display/AS72/EJB+invocations+from+a+remote+server+instance#
                
> JBoss AS 7 documentation cannot be exported to PDF
> --------------------------------------------------
>
>                 Key: WFLY-771
>                 URL: https://issues.jboss.org/browse/WFLY-771
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Hendy Irawan
>         Attachments: export_pdf.png, export_pdf1.png
>
>
> Most JBoss projects Confluence documentation, notably Arquillian, can be exported to PDF which is very handy for offline browsing and archive :
> 1. Click Tools > View in Hierarchy
> 2. Click Advanced tab
> 3. Click "Export to PDF"
> However, this feature is missing in the JBoss AS7 Confluence Space. It would be awesome if this is enabled, as JBoss AS7 is the flagship product of JBoss. This feature should also have a more prominent introduction, as people unfamiliar with Confluence unaware of this very useful feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 21:06:28 2014
From: issues at jboss.org (Claudio Miranda (JIRA))
Date: Tue, 21 Jan 2014 21:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-771) JBoss AS 7 documentation
 cannot be exported to PDF
In-Reply-To: <JIRA.12464006.1334337487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464006.1334337487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464006.1334337487000.5922.1390356388684@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claudio Miranda updated WFLY-771:
---------------------------------

    Attachment: export_pdf1.png
                export_pdf.png

    
> JBoss AS 7 documentation cannot be exported to PDF
> --------------------------------------------------
>
>                 Key: WFLY-771
>                 URL: https://issues.jboss.org/browse/WFLY-771
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Hendy Irawan
>         Attachments: export_pdf.png, export_pdf1.png
>
>
> Most JBoss projects Confluence documentation, notably Arquillian, can be exported to PDF which is very handy for offline browsing and archive :
> 1. Click Tools > View in Hierarchy
> 2. Click Advanced tab
> 3. Click "Export to PDF"
> However, this feature is missing in the JBoss AS7 Confluence Space. It would be awesome if this is enabled, as JBoss AS7 is the flagship product of JBoss. This feature should also have a more prominent introduction, as people unfamiliar with Confluence unaware of this very useful feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 21 21:40:28 2014
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 21 Jan 2014 21:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-412) NotSerializableException
 when running drools with engine.policy and kie.policy
In-Reply-To: <JIRA.12530032.1390330181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530032.1390330181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530032.1390330181000.5958.1390358428545@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved DROOLS-412.
----------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done


Fixed. Thanks for reporting Geoffrey.

6.0.0.GA.x: http://github.com/droolsjbpm/drools/commit/35f639130
6.0.x: http://github.com/droolsjbpm/drools/commit/e18f90dd0
master: http://github.com/droolsjbpm/drools/commit/bf6e02d04
                
> NotSerializableException when running drools with engine.policy and kie.policy
> ------------------------------------------------------------------------------
>
>                 Key: DROOLS-412
>                 URL: https://issues.jboss.org/browse/DROOLS-412
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>             Fix For: 6.1.0.Beta1
>
>
> {code}
> Exception in thread "main" org.optaplanner.benchmark.api.PlannerBenchmarkException: Benchmarking failed: failureCount (1). The exception of the firstFailureSingleBenchmarkRunner (comp01_FIRST_FIT_DECREASING) is chained.
> 	at org.optaplanner.benchmark.impl.PlannerBenchmarkRunner.benchmarkingEnded(PlannerBenchmarkRunner.java:204)
> 	at org.optaplanner.benchmark.impl.PlannerBenchmarkRunner.benchmark(PlannerBenchmarkRunner.java:86)
> 	at org.optaplanner.examples.common.app.CommonBenchmarkApp.buildAndBenchmark(CommonBenchmarkApp.java:29)
> 	at org.optaplanner.examples.curriculumcourse.app.CurriculumCourseBenchmarkApp.main(CurriculumCourseBenchmarkApp.java:47)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: java.io.NotSerializableException: org.drools.core.spi.ReturnValueExpression$SafeReturnValueExpression
> 	at org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:460)
> 	at org.drools.core.rule.Package.deepCloneIfAlreadyInUse(Package.java:723)
> 	at org.drools.core.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:565)
> 	at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:153)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:318)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieBase(KieContainerImpl.java:277)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieBase(KieContainerImpl.java:272)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildKieBase(ScoreDirectorFactoryConfig.java:340)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryConfig.java:282)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:187)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:175)
> 	at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:145)
> 	at org.optaplanner.benchmark.impl.SingleBenchmarkRunner.call(SingleBenchmarkRunner.java:72)
> 	at org.optaplanner.benchmark.impl.SingleBenchmarkRunner.call(SingleBenchmarkRunner.java:32)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 	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:724)
> Caused by: java.io.NotSerializableException: org.drools.core.spi.ReturnValueExpression$SafeReturnValueExpression
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1181)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.writeExternal(JavaAccumulatorFunctionExecutor.java:71)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Accumulate.writeExternal(Accumulate.java:106)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Pattern.writeExternal(Pattern.java:146)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at java.util.ArrayList.writeObject(ArrayList.java:710)
> 	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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.GroupElement.writeExternal(GroupElement.java:70)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Rule.writeExternal(Rule.java:150)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.JavaDialectRuntimeData.writeExternal(JavaDialectRuntimeData.java:135)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at java.util.HashMap.writeObject(HashMap.java:1100)
> 	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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.DialectRuntimeRegistry.writeExternal(DialectRuntimeRegistry.java:45)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Package.writeExternal(Package.java:181)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:454)
> 	... 18 more
> {code}
> To reproduce:
> {code}
> Config this run configuration after cloning optaplanner:
> Main class: org.optaplanner.examples.curriculumcourse.app.CurriculumCourseBenchmarkApp
> Vm options: -Xmx1536M -server -Djava.security.manager -Djava.security.policy=/home/gdesmet/tmp/support/edson/security/engine.policy -Dkie.security.policy=/home/gdesmet/tmp/support/edson/security/kie.policy
> working dir: $MODULE_DIR$ (optaplanner-examples)
> {code}
> Weird is that it didn't happen on all datasets. Looks like only on the once where the KieSession was created 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 issues at jboss.org  Tue Jan 21 21:40:28 2014
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 21 Jan 2014 21:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-412) NotSerializableException
 when running drools with engine.policy and kie.policy
In-Reply-To: <JIRA.12530032.1390330181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530032.1390330181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530032.1390330181000.5960.1390358428584@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed DROOLS-412.
--------------------------------


    
> NotSerializableException when running drools with engine.policy and kie.policy
> ------------------------------------------------------------------------------
>
>                 Key: DROOLS-412
>                 URL: https://issues.jboss.org/browse/DROOLS-412
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>             Fix For: 6.1.0.Beta1
>
>
> {code}
> Exception in thread "main" org.optaplanner.benchmark.api.PlannerBenchmarkException: Benchmarking failed: failureCount (1). The exception of the firstFailureSingleBenchmarkRunner (comp01_FIRST_FIT_DECREASING) is chained.
> 	at org.optaplanner.benchmark.impl.PlannerBenchmarkRunner.benchmarkingEnded(PlannerBenchmarkRunner.java:204)
> 	at org.optaplanner.benchmark.impl.PlannerBenchmarkRunner.benchmark(PlannerBenchmarkRunner.java:86)
> 	at org.optaplanner.examples.common.app.CommonBenchmarkApp.buildAndBenchmark(CommonBenchmarkApp.java:29)
> 	at org.optaplanner.examples.curriculumcourse.app.CurriculumCourseBenchmarkApp.main(CurriculumCourseBenchmarkApp.java:47)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: java.io.NotSerializableException: org.drools.core.spi.ReturnValueExpression$SafeReturnValueExpression
> 	at org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:460)
> 	at org.drools.core.rule.Package.deepCloneIfAlreadyInUse(Package.java:723)
> 	at org.drools.core.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:565)
> 	at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:153)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:318)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieBase(KieContainerImpl.java:277)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieBase(KieContainerImpl.java:272)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildKieBase(ScoreDirectorFactoryConfig.java:340)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryConfig.java:282)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:187)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:175)
> 	at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:145)
> 	at org.optaplanner.benchmark.impl.SingleBenchmarkRunner.call(SingleBenchmarkRunner.java:72)
> 	at org.optaplanner.benchmark.impl.SingleBenchmarkRunner.call(SingleBenchmarkRunner.java:32)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 	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:724)
> Caused by: java.io.NotSerializableException: org.drools.core.spi.ReturnValueExpression$SafeReturnValueExpression
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1181)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.writeExternal(JavaAccumulatorFunctionExecutor.java:71)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Accumulate.writeExternal(Accumulate.java:106)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Pattern.writeExternal(Pattern.java:146)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at java.util.ArrayList.writeObject(ArrayList.java:710)
> 	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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.GroupElement.writeExternal(GroupElement.java:70)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Rule.writeExternal(Rule.java:150)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.JavaDialectRuntimeData.writeExternal(JavaDialectRuntimeData.java:135)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at java.util.HashMap.writeObject(HashMap.java:1100)
> 	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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> 	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.DialectRuntimeRegistry.writeExternal(DialectRuntimeRegistry.java:45)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.rule.Package.writeExternal(Package.java:181)
> 	at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1456)
> 	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1427)
> 	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
> 	at org.drools.core.util.ClassUtils.deepClone(ClassUtils.java:454)
> 	... 18 more
> {code}
> To reproduce:
> {code}
> Config this run configuration after cloning optaplanner:
> Main class: org.optaplanner.examples.curriculumcourse.app.CurriculumCourseBenchmarkApp
> Vm options: -Xmx1536M -server -Djava.security.manager -Djava.security.policy=/home/gdesmet/tmp/support/edson/security/engine.policy -Dkie.security.policy=/home/gdesmet/tmp/support/edson/security/kie.policy
> working dir: $MODULE_DIR$ (optaplanner-examples)
> {code}
> Weird is that it didn't happen on all datasets. Looks like only on the once where the KieSession was created 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 issues at jboss.org  Wed Jan 22 01:48:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 22 Jan 2014 01:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.6006.1390373308735@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov reassigned WFLY-2785:
-------------------------------------------

    Assignee: Aleksandar Kostadinov  (was: Jason Greene)

    
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 01:48:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 22 Jan 2014 01:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.6008.1390373308832@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937750#comment-12937750 ] 

Aleksandar Kostadinov commented on WFLY-2785:
---------------------------------------------

This change seems to break test suite for wildfly, it was good for EAP. I'll have to find out the cause of this.
                
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 03:18:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Jan 2014 03:18:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to
 MDB @PreDestroy methods
In-Reply-To: <JIRA.12529009.1389281709000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529009.1389281709000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529009.1389281709000.6066.1390378709085@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2732:
---------------------------------

    Fix Version/s: 8.0.0.Final

    
> Injected EJB not available to MDB @PreDestroy methods
> -----------------------------------------------------
>
>                 Key: WFLY-2732
>                 URL: https://issues.jboss.org/browse/WFLY-2732
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Mustafa Musaji
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>         Attachments: MDBLifeCycleJAR.zip
>
>
> MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed.
> This was fixed in an RFE for Session Beans but does not seem to work 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 issues at jboss.org  Wed Jan 22 03:18:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Jan 2014 03:18:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2707) Filter.destroy() not called
 for undeployment
In-Reply-To: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528584.1388747435000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528584.1388747435000.6070.1390378709285@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2707.
----------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> Filter.destroy() not called for undeployment
> --------------------------------------------
>
>                 Key: WFLY-2707
>                 URL: https://issues.jboss.org/browse/WFLY-2707
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: CentOs/OpenJDK 7
>            Reporter: Andre Pankraz
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> ServletContextListener.contextDestroyed() is called reliably at undeployment time.
> But the destroy() methods of  javax.servlet.Filters are never called.
> The filter is not explicetely in the web.xml, it's automatically detected and initialized via init() at deployment, but destroy() is never called.
> JavaMelody cannot shutdown it's timers because of this:
> See last remarks in http://code.google.com/p/javamelody/issues/detail?id=360

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 03:18:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Jan 2014 03:18:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2688) jsp with empty content prolog
	gives error
In-Reply-To: <JIRA.12528413.1387960062000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528413.1387960062000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528413.1387960062000.6074.1390378709539@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2688.
----------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> jsp with empty content prolog gives error
> -----------------------------------------
>
>                 Key: WFLY-2688
>                 URL: https://issues.jboss.org/browse/WFLY-2688
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: fiorenzo pizza
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> i f you deploy  jsp pages with 1 empty row  and after the content, like:
> --------------------
> <%  
>   response.sendRedirect("first.jsf");  
> %>  
> ----------------------------------
> the error in the log is:
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /index.jsp: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
>         at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:298) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:126) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:188) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:115) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:74) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jsp.index_jsp._jspService(index_jsp.java:66)
>         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654) [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 03:32:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Wed, 22 Jan 2014 03:32:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.6105.1390379549052@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937771#comment-12937771 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

While trying to analyze this by myself a thing came to mind I want to document here:

we are using a JRuby / Rails 4 app and had issues with a CipherError, documented here: https://github.com/jruby/jruby/wiki/UnlimitedStrengthCrypto . We had the first solution working with installing the jars. I have no idea if this affects the issue WFLY-2778, but I thought I should share this info. Meanwhile we tried the other solution but our servers end up with the cpu load after some time as well.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 03:38:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Jan 2014 03:38:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.6116.1390379909114@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937775#comment-12937775 ] 

Stuart Douglas commented on WFLY-2778:
--------------------------------------

I may have a solution in upstream Undertow. I will cut a release shortly and merge it upstream.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 04:02:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Wed, 22 Jan 2014 04:02:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.6190.1390381349887@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937785#comment-12937785 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Thanks Stuart. As soon as it is available we are going to test it.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 05:12:28 2014
From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=)
Date: Wed, 22 Jan 2014 05:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.6333.1390385548972@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937811#comment-12937811 ] 

P?tr Andreev commented on WFLY-2739:
------------------------------------

Sorry, i ported them from windows and discovered CR/LFs problem after commit- i`ll fix it after solving my local GIT issues... 
                
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Jan 22 05:16:29 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 22 Jan 2014 05:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.6368.1390385789812@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937815#comment-12937815 ] 

Geoffrey De Smet commented on DROOLS-411:
-----------------------------------------

Another dataset, sprint01_1week.xml (use import button to get it) suffers from this problem too, but it's hard to notice because it takes a very long time to OOM in that case.

This means that it's possible that the other datasets suffer from it too, making it not so rare...
                
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Wed Jan 22 05:34:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Jan 2014 05:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2786) wildfly undertow can't add
 <sso cache-container="web" cache-name="sso" domain="myDomain"
In-Reply-To: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525423.1384773291000.6410.1390386868657@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved UNDERTOW-134 to WFLY-2786:
-----------------------------------------------

        Project: WildFly  (was: Undertow)
            Key: WFLY-2786  (was: UNDERTOW-134)
    Component/s: Web (Undertow)
                     (was: Servlet)
                     (was: Core)
       Security: Public

    
> wildfly undertow can't add <sso cache-container="web" cache-name="sso" domain="myDomain"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2786
>                 URL: https://issues.jboss.org/browse/WFLY-2786
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: xiaojie Ma
>            Assignee: Stuart Douglas
>
> I want to configure the sso for wildfly without sso server: 
> For example ?JBOSS7
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
>   <sso domain="localhost" reauthenticate="false"/>
>   </virtual-server>
> or
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
> <sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
>   </virtual-server>
> I add  " <sso domain="localhost" reauthenticate="false"/>"
>  between the <location> and< /location>:
> <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content">
>                    <sso domain="localhost" reauthenticate="false"/>
>                     </location>
>              </host>
> if so,I can't start the 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 issues at jboss.org  Wed Jan 22 05:34:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Jan 2014 05:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2786) wildfly undertow can't add
 <sso cache-container="web" cache-name="sso" domain="myDomain"
In-Reply-To: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525423.1384773291000.6414.1390386868808@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2786:
------------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> wildfly undertow can't add <sso cache-container="web" cache-name="sso" domain="myDomain"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2786
>                 URL: https://issues.jboss.org/browse/WFLY-2786
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: xiaojie Ma
>            Assignee: Tomaz Cerar
>
> I want to configure the sso for wildfly without sso server: 
> For example ?JBOSS7
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
>   <sso domain="localhost" reauthenticate="false"/>
>   </virtual-server>
> or
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
> <sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
>   </virtual-server>
> I add  " <sso domain="localhost" reauthenticate="false"/>"
>  between the <location> and< /location>:
> <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content">
>                    <sso domain="localhost" reauthenticate="false"/>
>                     </location>
>              </host>
> if so,I can't start the 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 issues at jboss.org  Wed Jan 22 05:46:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 05:46:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1774) Avoid buffer allocations when
 encoding a long for appending to another buffer
In-Reply-To: <JIRA.12529729.1389999342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529729.1389999342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529729.1389999342000.6430.1390387588643@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1774.
----------------------------

      Assignee: Bela Ban  (was: Sanne Grinovero)
    Resolution: Done

    
> Avoid buffer allocations when encoding a long for appending to another buffer
> -----------------------------------------------------------------------------
>
>                 Key: JGRP-1774
>                 URL: https://issues.jboss.org/browse/JGRP-1774
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Sanne Grinovero
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When a long gets encoded, a function is used which returns a {{byte[]}}.
> There are some hot methods which invoke this encoding, to then append the buffer's content into a _DataOutput_. Especially for the case of these hot methods we should rather have the function write the encoded form directly into the _DataOutput_.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 06:14:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 22 Jan 2014 06:14:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2786) wildfly undertow can't add
 <sso cache-container="web" cache-name="sso" domain="myDomain"
In-Reply-To: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525423.1384773291000.6472.1390389269097@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2786:
------------------------------

      Fix Version/s: 8.0.0.Final
           Priority: Critical  (was: Major)
    Forum Reference: https://community.jboss.org/message/846078

    
> wildfly undertow can't add <sso cache-container="web" cache-name="sso" domain="myDomain"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2786
>                 URL: https://issues.jboss.org/browse/WFLY-2786
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: xiaojie Ma
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> I want to configure the sso for wildfly without sso server: 
> For example ?JBOSS7
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
>   <sso domain="localhost" reauthenticate="false"/>
>   </virtual-server>
> or
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
> <sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
>   </virtual-server>
> I add  " <sso domain="localhost" reauthenticate="false"/>"
>  between the <location> and< /location>:
> <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content">
>                    <sso domain="localhost" reauthenticate="false"/>
>                     </location>
>              </host>
> if so,I can't start the 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 issues at jboss.org  Wed Jan 22 06:14:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 22 Jan 2014 06:14:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2786) wildfly undertow can't add
 <sso cache-container="web" cache-name="sso" domain="myDomain"
In-Reply-To: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525423.1384773291000.6477.1390389269251@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2786:
------------------------------

    Comment: was deleted

(was: https://community.jboss.org/message/846078?et=watches.email.thread 
This's a detail description !)

    
> wildfly undertow can't add <sso cache-container="web" cache-name="sso" domain="myDomain"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2786
>                 URL: https://issues.jboss.org/browse/WFLY-2786
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: xiaojie Ma
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> I want to configure the sso for wildfly without sso server: 
> For example ?JBOSS7
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
>   <sso domain="localhost" reauthenticate="false"/>
>   </virtual-server>
> or
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
> <sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
>   </virtual-server>
> I add  " <sso domain="localhost" reauthenticate="false"/>"
>  between the <location> and< /location>:
> <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content">
>                    <sso domain="localhost" reauthenticate="false"/>
>                     </location>
>              </host>
> if so,I can't start the 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 issues at jboss.org  Wed Jan 22 06:16:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2639)
 HttpServletRequest.getAuthType returns incorrect value
In-Reply-To: <JIRA.12527729.1386786562000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527729.1386786562000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527729.1386786562000.6485.1390389390191@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2639:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> HttpServletRequest.getAuthType returns incorrect value
> ------------------------------------------------------
>
>                 Key: WFLY-2639
>                 URL: https://issues.jboss.org/browse/WFLY-2639
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Arun Gupta
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 9.0.0.CR1
>
>
> HttpServletRequest.getAuthType returns "Programatic" if login/logout methods are used.
> Javadoc says:
> one of the static members BASIC_AUTH, FORM_AUTH, CLIENT_CERT_AUTH, DIGEST_AUTH (suitable for == comparison) or the container-specific string indicating the authentication scheme, or null if the request was not authenticated.
> "Programatic" is not one of the expected 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 issues at jboss.org  Wed Jan 22 06:16:30 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 22 Jan 2014 06:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2786) wildfly undertow can't add
 <sso cache-container="web" cache-name="sso" domain="myDomain"
In-Reply-To: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525423.1384773291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525423.1384773291000.6498.1390389390479@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2786:
------------------------------

    Description: 
I want to configure the sso for wildfly without sso server: 
For example ?JBOSS7
{code:xml}
<virtual-server name="default-host" enable-welcome-root="true">
  <alias name="localhost"/>
  <sso domain="localhost" reauthenticate="false"/>
  </virtual-server>
{code}
or
{code:xml}
<virtual-server name="default-host" enable-welcome-root="true">
  <alias name="localhost"/>
<sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
  </virtual-server>
{code}

I add  {code}" <sso domain="localhost" reauthenticate="false"/>" {code}
 between the <location> and< /location>:
{code:xml}
<host name="default-host" alias="localhost">
                    <location name="/" handler="welcome-content">
                   <sso domain="localhost" reauthenticate="false"/>
                    </location>
             </host>
{code}
if so,I can't start the wildfly.

  was:
I want to configure the sso for wildfly without sso server: 
For example ?JBOSS7

<virtual-server name="default-host" enable-welcome-root="true">
  <alias name="localhost"/>
  <sso domain="localhost" reauthenticate="false"/>
  </virtual-server>
or
<virtual-server name="default-host" enable-welcome-root="true">
  <alias name="localhost"/>
<sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
  </virtual-server>

I add  " <sso domain="localhost" reauthenticate="false"/>"
 between the <location> and< /location>:
<host name="default-host" alias="localhost">
                    <location name="/" handler="welcome-content">
                   <sso domain="localhost" reauthenticate="false"/>
                    </location>
             </host>
if so,I can't start the wildfly.


    
> wildfly undertow can't add <sso cache-container="web" cache-name="sso" domain="myDomain"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2786
>                 URL: https://issues.jboss.org/browse/WFLY-2786
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: xiaojie Ma
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> I want to configure the sso for wildfly without sso server: 
> For example ?JBOSS7
> {code:xml}
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
>   <sso domain="localhost" reauthenticate="false"/>
>   </virtual-server>
> {code}
> or
> {code:xml}
> <virtual-server name="default-host" enable-welcome-root="true">
>   <alias name="localhost"/>
> <sso cache-container="web" cache-name="sso" domain="myDomain" reauthenticate="true"/>
>   </virtual-server>
> {code}
> I add  {code}" <sso domain="localhost" reauthenticate="false"/>" {code}
>  between the <location> and< /location>:
> {code:xml}
> <host name="default-host" alias="localhost">
>                     <location name="/" handler="welcome-content">
>                    <sso domain="localhost" reauthenticate="false"/>
>                     </location>
>              </host>
> {code}
> if so,I can't start the 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 issues at jboss.org  Wed Jan 22 06:16:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2635) HTTP Management Interface
	Configuration
In-Reply-To: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527655.1386765053000.6502.1390389390624@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2635:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> HTTP Management Interface Configuration
> ---------------------------------------
>
>                 Key: WFLY-2635
>                 URL: https://issues.jboss.org/browse/WFLY-2635
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine 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 issues at jboss.org  Wed Jan 22 06:16:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2568) Custom authentication
 mechanism configuration - Deployment Level
In-Reply-To: <JIRA.12526046.1385389933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526046.1385389933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526046.1385389933000.6504.1390389390656@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2568:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Custom authentication mechanism configuration - Deployment Level
> ----------------------------------------------------------------
>
>                 Key: WFLY-2568
>                 URL: https://issues.jboss.org/browse/WFLY-2568
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:18:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:18:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2567) Custom authentication
 mechanism definition - Subsystem Level
In-Reply-To: <JIRA.12526043.1385388220000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526043.1385388220000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526043.1385388220000.6508.1390389508989@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2567:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Custom authentication mechanism definition - Subsystem Level
> ------------------------------------------------------------
>
>                 Key: WFLY-2567
>                 URL: https://issues.jboss.org/browse/WFLY-2567
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:18:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:18:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2229) Add support for PKCS12
 Keystores in security realms.
In-Reply-To: <JIRA.12502310.1381144389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502310.1381144389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502310.1381144389000.6515.1390389509152@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2229:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Add support for PKCS12 Keystores in security realms.
> ----------------------------------------------------
>
>                 Key: WFLY-2229
>                 URL: https://issues.jboss.org/browse/WFLY-2229
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:18:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:18:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2111) Enhance CallbackHandler /
 Realm Integration with lifecycle callbacks.
In-Reply-To: <JIRA.12501003.1379588777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501003.1379588777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501003.1379588777000.6523.1390389509396@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2111:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Enhance CallbackHandler / Realm Integration with lifecycle callbacks.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2111
>                 URL: https://issues.jboss.org/browse/WFLY-2111
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Remoting, Security, Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:18:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:18:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2036) Review of
	AbstractControllerTestBase
In-Reply-To: <JIRA.12500390.1378814554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500390.1378814554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500390.1378814554000.6528.1390389509536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2036:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Review of AbstractControllerTestBase
> ------------------------------------
>
>                 Key: WFLY-2036
>                 URL: https://issues.jboss.org/browse/WFLY-2036
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:20:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:20:29 -0500 (EST)
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.6544.1390389629132@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: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> 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
>      Security Level: Public(Everyone can see) 
>          Components: Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:20:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:20:29 -0500 (EST)
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.6573.1390389629792@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: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> 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
>      Security Level: Public(Everyone can see) 
>          Components: Remoting, Security
>            Reporter: jaikiran pai
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:20:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:20:30 -0500 (EST)
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.6586.1390389630077@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: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Connection Reauthentication and Security Propagation
> ----------------------------------------------------
>
>                 Key: WFLY-447
>                 URL: https://issues.jboss.org/browse/WFLY-447
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Wed Jan 22 06:20:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:20:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-362) provide means to specify
 allowed ciphers for management https or change default to exclude weak
 ciphers
In-Reply-To: <JIRA.12473935.1346965907000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473935.1346965907000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473935.1346965907000.6589.1390389630139@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-362:
----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> provide means to specify allowed ciphers for management https or change default to exclude weak ciphers
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-362
>                 URL: https://issues.jboss.org/browse/WFLY-362
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: R Stokoe
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Provide means to specify allowed ciphers for 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 issues at jboss.org  Wed Jan 22 06:26:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:26:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2787) Upgrade to JBoss SASL
	1.0.4.Final
In-Reply-To: <JIRA.12530075.1390389919137@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530075.1390389919137@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530075.1390389919137.6598.1390389988824@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2787:
--------------------------------------

             Summary: Upgrade to JBoss SASL 1.0.4.Final
                 Key: WFLY-2787
                 URL: https://issues.jboss.org/browse/WFLY-2787
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.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 issues at jboss.org  Wed Jan 22 06:28:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:28:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SASL-44) Release JBoss SASL 1.0.4.Final
In-Reply-To: <JIRA.12530076.1390389992110@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530076.1390389992110@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530076.1390389992110.6603.1390390108520@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SASL-44:
------------------------------------

             Summary: Release JBoss SASL 1.0.4.Final
                 Key: SASL-44
                 URL: https://issues.jboss.org/browse/SASL-44
             Project: JBoss SASL Provider
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.0.4.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 issues at jboss.org  Wed Jan 22 06:38:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 06:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1782) Util.objectToByteBuffer() is
	inefficient
In-Reply-To: <JIRA.12529853.1390219484000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529853.1390219484000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529853.1390219484000.6622.1390390708578@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1782:
---------------------------

    Description: When the type is a string, we create an unneeded byte[] buffer  (was: When the type is a string, we create 2 copies. Replace this with 1 copy.)

    
> Util.objectToByteBuffer() is inefficient
> ----------------------------------------
>
>                 Key: JGRP-1782
>                 URL: https://issues.jboss.org/browse/JGRP-1782
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> When the type is a string, we create an unneeded byte[] buffer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 06:44:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 06:44:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1776) RSVP: flag ACKs as OOB and
	DONT_BUNDLE
In-Reply-To: <JIRA.12529842.1390215935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529842.1390215935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529842.1390215935000.6627.1390391068635@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1776:
---------------------------

    Fix Version/s: 3.5

    
> RSVP: flag ACKs as OOB and DONT_BUNDLE
> --------------------------------------
>
>                 Key: JGRP-1776
>                 URL: https://issues.jboss.org/browse/JGRP-1776
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Trivial
>             Fix For: 3.5
>
>
> Otherwise they might get delivered in a batch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 06:46:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 06:46:29 -0500 (EST)
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.6638.1390391189116@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 closed JGRP-1686.
--------------------------

    Resolution: Rejected

    
> 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 issues at jboss.org  Wed Jan 22 06:48:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 06:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1673) TCPPING not scanning in
	parallel
In-Reply-To: <JIRA.12498292.1376002577000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498292.1376002577000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498292.1376002577000.6641.1390391308655@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1673.
----------------------------

    Resolution: Done

    
> TCPPING not scanning in parallel
> --------------------------------
>
>                 Key: JGRP-1673
>                 URL: https://issues.jboss.org/browse/JGRP-1673
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Bela Ban
>
> JGRP-375 was incorrectly implemented.
> Instead of replacing the down_prot.down in TCPPING.sendGetMembersRequest with a parallel version, it just added a 2nd copy run in parallel after the first finished.
> The original down_prot.down call should have been 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 issues at jboss.org  Wed Jan 22 06:48:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 06:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1631) Missing classes in maven build
In-Reply-To: <JIRA.12491694.1368476882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491694.1368476882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491694.1368476882000.6645.1390391308855@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1631.
----------------------------

    Resolution: Done

    
> Missing classes in maven build
> ------------------------------
>
>                 Key: JGRP-1631
>                 URL: https://issues.jboss.org/browse/JGRP-1631
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.14
>            Reporter: Dennis Reed
>            Assignee: Bela Ban
>
> The maven build of JGroups (used by EAP) is missing classes compared to the community build using ant.
> (Everything in org.jgroups.tests.*, including Probe, McastSenderTest/MCastReceiverTest, and LargeState, which are used for debugging problems in EAP clusters).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 06:52:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SASL-44) Release JBoss SASL 1.0.4.Final
In-Reply-To: <JIRA.12530076.1390389992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530076.1390389992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530076.1390389992000.6651.1390391548594@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SASL-44.
----------------------------------

    Resolution: Done

    
> Release JBoss SASL 1.0.4.Final
> ------------------------------
>
>                 Key: SASL-44
>                 URL: https://issues.jboss.org/browse/SASL-44
>             Project: JBoss SASL Provider
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.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 issues at jboss.org  Wed Jan 22 06:52:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SASL-40) Update the local authentication
 mechanism to allow permissions to be specified for the challenge file.
In-Reply-To: <JIRA.12486810.1362763394000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486810.1362763394000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486810.1362763394000.6654.1390391548757@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-40:
---------------------------------

    Fix Version/s: 1.0.5.CR1
                       (was: 1.0.4.Final)

    
> Update the local authentication mechanism to allow permissions to be specified for the challenge file.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: SASL-40
>                 URL: https://issues.jboss.org/browse/SASL-40
>             Project: JBoss SASL Provider
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.5.CR1
>
>
> (This would include switching to a dependency on Java 7 server side at least)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 06:52:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SASL-39) Support for stronger hashes as
 alternatives to MD5
In-Reply-To: <JIRA.12479914.1354008365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479914.1354008365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479914.1354008365000.6657.1390391548845@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-39:
---------------------------------

    Fix Version/s: 1.0.5.CR1
                       (was: 1.0.4.Final)

    
> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
>                 Key: SASL-39
>                 URL: https://issues.jboss.org/browse/SASL-39
>             Project: JBoss SASL Provider
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.5.CR1
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 06:52:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SASL-11) From RFC-2831 a realm name can
 contain whitespace,
 this means using space as the delimiter for possible realms is incorrect
In-Reply-To: <JIRA.12447706.1316779828000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447706.1316779828000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447706.1316779828000.6660.1390391548993@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-11:
---------------------------------

    Fix Version/s: 1.0.5.CR1
                       (was: 1.0.4.Final)

    
> From RFC-2831 a realm name can contain whitespace, this means using space as the delimiter for possible realms is incorrect
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SASL-11
>                 URL: https://issues.jboss.org/browse/SASL-11
>             Project: JBoss SASL Provider
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.5.CR1
>
>
> By using space as the separator a single realm name that contains a space is split into two realms.
> Either support quoted realm names if they contain a space or choose a different delimiter - (A different delimiter other than a control character may be difficult as the rest can appear in a realm 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 issues at jboss.org  Wed Jan 22 06:52:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 06:52:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SASL-10) Pluggable nonce handling
	strategy
In-Reply-To: <JIRA.12446879.1315944468000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446879.1315944468000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446879.1315944468000.6662.1390391549051@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-10:
---------------------------------

    Fix Version/s: 1.0.5.CR1
                       (was: 1.0.4.Final)

    
> Pluggable nonce handling strategy
> ---------------------------------
>
>                 Key: SASL-10
>                 URL: https://issues.jboss.org/browse/SASL-10
>             Project: JBoss SASL Provider
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.5.CR1
>
>
> Implement a pluggable nonce handling strategy.
> At the very least we need to be able to switch to using a SecureRandom instead of Random.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 07:24:28 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 22 Jan 2014 07:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2788) Upgrade PicketLink to
	2.5.2.Final
In-Reply-To: <JIRA.12530088.1390393405320@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530088.1390393405320@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530088.1390393405320.6723.1390393468584@jira02.app.mwc.hst.phx2.redhat.com>

Pedro Igor created WFLY-2788:
--------------------------------

             Summary: Upgrade PicketLink to 2.5.2.Final
                 Key: WFLY-2788
                 URL: https://issues.jboss.org/browse/WFLY-2788
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.CR1
            Reporter: Pedro Igor
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Final


Upgrade to the latest released PicketLink 2.5.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 issues at jboss.org  Wed Jan 22 07:24:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 07:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2787) Upgrade to JBoss SASL
	1.0.4.Final
In-Reply-To: <JIRA.12530075.1390389919000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530075.1390389919000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530075.1390389919000.6725.1390393468677@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2787:
-----------------------------------

    Issue Type: Component  Upgrade  (was: Task)

    
> Upgrade to JBoss SASL 1.0.4.Final
> ---------------------------------
>
>                 Key: WFLY-2787
>                 URL: https://issues.jboss.org/browse/WFLY-2787
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.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 issues at jboss.org  Wed Jan 22 07:30:28 2014
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 22 Jan 2014 07:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2788) Upgrade PicketLink to
	2.5.2.Final
In-Reply-To: <JIRA.12530088.1390393405000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530088.1390393405000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530088.1390393405000.6746.1390393828771@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-2788:
-----------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5746

    
> Upgrade PicketLink to 2.5.2.Final
> ---------------------------------
>
>                 Key: WFLY-2788
>                 URL: https://issues.jboss.org/browse/WFLY-2788
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Upgrade to the latest released PicketLink 2.5.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 issues at jboss.org  Wed Jan 22 07:34:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 07:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1776) RSVP: flag ACKs as OOB and
	DONT_BUNDLE
In-Reply-To: <JIRA.12529842.1390215935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529842.1390215935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529842.1390215935000.6756.1390394068510@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1776.
----------------------------

    Resolution: Done

    
> RSVP: flag ACKs as OOB and DONT_BUNDLE
> --------------------------------------
>
>                 Key: JGRP-1776
>                 URL: https://issues.jboss.org/browse/JGRP-1776
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Trivial
>             Fix For: 3.5
>
>
> Otherwise they might get delivered in a batch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 07:34:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 07:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1782) Util.objectToByteBuffer() is
	inefficient
In-Reply-To: <JIRA.12529853.1390219484000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529853.1390219484000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529853.1390219484000.6758.1390394068604@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1782.
----------------------------

    Resolution: Done

    
> Util.objectToByteBuffer() is inefficient
> ----------------------------------------
>
>                 Key: JGRP-1782
>                 URL: https://issues.jboss.org/browse/JGRP-1782
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> When the type is a string, we create an unneeded byte[] buffer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 09:24:28 2014
From: issues at jboss.org (Johnathon Lee (JIRA))
Date: Wed, 22 Jan 2014 09:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2789) Remote client transaction
 timeout values are overwrote by hardcoded values
In-Reply-To: <JIRA.12530096.1390399141000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530096.1390399141000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530096.1390399141000.6973.1390400668574@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee moved JBEAP-44 to WFLY-2789:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-2789  (was: JBEAP-44)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s:     (was: EAP 6.2.0.Final)
          Component/s: EJB
                           (was: EJB)
             Security: Public

    
> Remote client transaction timeout values are overwrote by hardcoded values
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2789
>                 URL: https://issues.jboss.org/browse/WFLY-2789
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Johnathon Lee
>            Assignee: David Lloyd
>
> The EJB3 interceptor is not using client values for timeouts,  this is a problem for users trying to use EJB for transaction propagation.
> Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBRemoteTransactionPropagatingInterceptor.java:
>     private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception {
>         final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager();
>         final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID);
>         if (alreadyCreatedTx != null) {
>             // resume the already created tx
>             transactionManager.resume(alreadyCreatedTx);
>         } else {
>             // begin a new tx and add it to the tx repository
>             // TODO: Fix the tx timeout (which currently is passed as 300 seconds)
>             final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300);
>             // associate this tx with the thread
>             transactionManager.resume(newSubOrdinateTx);
>         }
>     }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 09:24:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 09:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2789) Remote client transaction
 timeout values are overwrote by hardcoded values
In-Reply-To: <JIRA.12530096.1390399141000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530096.1390399141000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530096.1390399141000.6977.1390400668676@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2789:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056585

    
> Remote client transaction timeout values are overwrote by hardcoded values
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2789
>                 URL: https://issues.jboss.org/browse/WFLY-2789
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Johnathon Lee
>            Assignee: David Lloyd
>
> The EJB3 interceptor is not using client values for timeouts,  this is a problem for users trying to use EJB for transaction propagation.
> Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBRemoteTransactionPropagatingInterceptor.java:
>     private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception {
>         final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager();
>         final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID);
>         if (alreadyCreatedTx != null) {
>             // resume the already created tx
>             transactionManager.resume(alreadyCreatedTx);
>         } else {
>             // begin a new tx and add it to the tx repository
>             // TODO: Fix the tx timeout (which currently is passed as 300 seconds)
>             final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300);
>             // associate this tx with the thread
>             transactionManager.resume(newSubOrdinateTx);
>         }
>     }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 09:38:28 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 22 Jan 2014 09:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2790) Upgrade netty-xnio-transport
 to 0.1.1.Final
In-Reply-To: <JIRA.12530101.1390401477680@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530101.1390401477680@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530101.1390401477680.7012.1390401508806@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2790:
---------------------------------

             Summary: Upgrade netty-xnio-transport to 0.1.1.Final
                 Key: WFLY-2790
                 URL: https://issues.jboss.org/browse/WFLY-2790
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.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 issues at jboss.org  Wed Jan 22 09:40:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 09:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.7016.1390401628653@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-411:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056599

    
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Wed Jan 22 09:40:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 09:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.7023.1390401628800@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937891#comment-12937891 ] 

RH Bugzilla Integration commented on DROOLS-411:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1056599|https://bugzilla.redhat.com/show_bug.cgi?id=1056599] from NEW to ASSIGNED
                
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Wed Jan 22 09:42:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 09:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.7028.1390401748756@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937893#comment-12937893 ] 

RH Bugzilla Integration commented on WFLY-2782:
-----------------------------------------------

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 1055912|https://bugzilla.redhat.com/show_bug.cgi?id=1055912] from POST to MODIFIED
                
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 10:14:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 22 Jan 2014 10:14:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1781) Message: write/read the
 payload last when marshalling
In-Reply-To: <JIRA.12529852.1390219278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529852.1390219278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529852.1390219278000.7122.1390403669499@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937910#comment-12937910 ] 

Bela Ban commented on JGRP-1781:
--------------------------------

When moving the payload to the end, we might omit the length field (int) when writing / reading a single message, as the length is implied as the current position until the end of the buffer.
                
> Message: write/read the payload last when marshalling
> -----------------------------------------------------
>
>                 Key: JGRP-1781
>                 URL: https://issues.jboss.org/browse/JGRP-1781
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When (un)marshalling a message, we process the fields in this order:
> # Sender and receiver addresses
> # Flags
> # Payload
> # Headers
> I'd like to change this to move processing of the payload to the end because
> * If payload refers to a different buffer (JGRP-1773), then we don't need to read the bytes, but currently have to skip N bytes to read the headers. If the payload was at the end, this wouldn't be needed
> * Once we use NIO.2 and gathering writes, we'd pass a couple of buffers to the socket write and therefore it's simpler if the payload is written last. Ditto for scattering reads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 10:46:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 10:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.7235.1390405589391@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937931#comment-12937931 ] 

RH Bugzilla Integration commented on DROOLS-411:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1056599|https://bugzilla.redhat.com/show_bug.cgi?id=1056599] from ASSIGNED to MODIFIED
                
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Wed Jan 22 10:48:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 22 Jan 2014 10:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.7239.1390405708890@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937932#comment-12937932 ] 

Scott Marlow commented on WFLY-2387:
------------------------------------

{quote}
E.g. think about the pathalogical case of an entity listener injecting an EntityManager via CDI. We are required by spec to support this, but it can't happen until hibernate has started, therefore you cannot create the listener instance until after hibernate has started to give weld a chance to start properly. 
{quote}

Is there a CDI spec section that states this use case specifically?  It would be good to have the CDI spec section so that we can raise this issue with the JPA expert group.

I'm not against changing Hibernate as an extension, as recommended here but it seems to me, that there is more discussion needed for this issue.
                
> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Final
>
>         Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 10:48:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 22 Jan 2014 10:48:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.7256.1390405709291@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-411.
--------------------------------

    Fix Version/s: 6.0.1.Final
       Resolution: Done

    
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Wed Jan 22 11:04:28 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 22 Jan 2014 11:04:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2791) Remove jboss-marshalling mvn
 dependency from the management protocol
In-Reply-To: <JIRA.12530116.1390406595011@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530116.1390406595011@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530116.1390406595011.7270.1390406668505@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-2791:
-----------------------------------------

             Summary: Remove jboss-marshalling mvn dependency from the management protocol
                 Key: WFLY-2791
                 URL: https://issues.jboss.org/browse/WFLY-2791
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.Final


The wildfly-protocol depends on jboss-marshalling although it should not be used for a while now. We need to verify that it's not used any more and remove 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 issues at jboss.org  Wed Jan 22 11:06:29 2014
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 22 Jan 2014 11:06:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.7286.1390406789772@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-411:
------------------------------------

    Fix Version/s: 6.1.0.Beta1
                       (was: 6.0.1.Final)

    
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Wed Jan 22 11:20:29 2014
From: issues at jboss.org (Scott Hasse (JIRA))
Date: Wed, 22 Jan 2014 11:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1389) Log API dependencies should be
 included automatically in deployments
In-Reply-To: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442444.1311346401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442444.1311346401000.7331.1390407629140@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12937949#comment-12937949 ] 

Scott Hasse commented on AS7-1389:
----------------------------------

I am afraid I might unfortunately be continuing my quest for understanding without your assistance.  But in either case, in an effort to better understand your viewpoint, it seems to me that point 2) above makes the next strongest case for a "default enabled" visibility setting.  If truly the vast majority of users (or perhaps customers anyway) want it that way, then it might very well make sense to leave the visibility enabled by default even if it does not make sense for other reasons.  In that spirit I think it makes sense to look more closely at the numbers you have stated.

Honestly, in my experience your "99% of the time users want to have centralized logging" number seems vastly overstated.  The three large RedHat ISV's I've worked with each bundled their own logging implementation and configuration specifically designed to isolate their application logging from the container logging.  In addition I've worked with about a dozen smaller application vendors (not officially RedHat ISVs) only one of which actually wanted their logging intermingled with server.log entries.  In working with various clients, I've encountered over 600 custom in-house written applications.  The vast majority of those (over 95%) bundled their own logging implementations and configurations.  This has of course required the additional hassle of configuring isolated classloader repositories in many cases, but apparently those implementers thought it was worth the additional hassle to be able to isolate their logging.

My general impression of some of the reasons why people desire container logs to be separated from application logs is:
1) Different log archiving and retention requirements
2) Different security requirements for log visibility
3) Different log schema/patterns in the application log content 
4) Wanting to do all of the above without having merge/unmerge application-level logging configuration in a container configuration during application deployment/undeployment
5) With multiple applications in one container (or multiple copies of the same application in one container), not wanting to interleave those application logs with each other, and being able to configure the same logging category from different applications or different copies of the same application differently 
6) Avoiding specific defects in the container-provided logging implementation
7) Application-level operational control of application-specific logging without endangering container logging settings
8) Having the application's logging configuration be portable with the application deployable artifact between container instances and container vendors

All of that is of course my real but admittedly anecdotal experience.  Can you help me understand in more depth your 99% number above and the reasons people in your experience seem to desire interleaved logging?  Also, does RedHat have hard numbers from the community, ISVs and support customers to actually quantify this number so we can come to a better understanding of the reality of the situation?

Regards,

Scott
                
> Log API dependencies should be included automatically in deployments
> --------------------------------------------------------------------
>
>                 Key: AS7-1389
>                 URL: https://issues.jboss.org/browse/AS7-1389
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 7.1.0.Final
>
>
> The following log APIs should be included by deployments by default:
> * {{org.slf4j}}
> * {{org.apache.commons.logging}}
> * {{org.log4j}}
> These dependencies should override the deployment's versions of these libraries unless explicitly excluded by {{jboss-deployment-structure.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 issues at jboss.org  Wed Jan 22 11:54:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 11:54:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2792) Upgrade Java EE 7 Spec APIs
 to .Final versions
In-Reply-To: <JIRA.12530122.1390409593431@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530122.1390409593431@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530122.1390409593431.7399.1390409668548@jira02.app.mwc.hst.phx2.redhat.com>

Shelly McGowan created WFLY-2792:
------------------------------------

             Summary: Upgrade Java EE 7 Spec APIs to .Final versions
                 Key: WFLY-2792
                 URL: https://issues.jboss.org/browse/WFLY-2792
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: EE
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan
             Fix For: 8.0.0.Final


Specifically:
org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.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 issues at jboss.org  Wed Jan 22 12:04:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:04:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2793) Upgrade to Remoting JMX
	2.0.0.Final
In-Reply-To: <JIRA.12530123.1390410173422@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530123.1390410173422@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530123.1390410173422.7474.1390410268961@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2793:
--------------------------------------

             Summary: Upgrade to Remoting JMX 2.0.0.Final
                 Key: WFLY-2793
                 URL: https://issues.jboss.org/browse/WFLY-2793
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JMX
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.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 issues at jboss.org  Wed Jan 22 12:08:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-79) Release Remoting JMX
	2.0.0.Final
In-Reply-To: <JIRA.12530124.1390410446175@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530124.1390410446175@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530124.1390410446175.7479.1390410508636@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-79:
--------------------------------------

             Summary: Release Remoting JMX 2.0.0.Final
                 Key: REMJMX-79
                 URL: https://issues.jboss.org/browse/REMJMX-79
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.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 issues at jboss.org  Wed Jan 22 12:16:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-80) Bring dependencies in-line
	with WildFly
In-Reply-To: <JIRA.12530127.1390410919845@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530127.1390410919845@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530127.1390410919845.7512.1390410990039@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-80:
--------------------------------------

             Summary: Bring dependencies in-line with WildFly
                 Key: REMJMX-80
                 URL: https://issues.jboss.org/browse/REMJMX-80
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.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 issues at jboss.org  Wed Jan 22 12:42:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 22 Jan 2014 12:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2794) FileSystemPathArgument
 doesn't translate paths in getValue(args, required)
In-Reply-To: <JIRA.12530131.1390412505684@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530131.1390412505684@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530131.1390412505684.7556.1390412548745@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-2794:
---------------------------------------

             Summary: FileSystemPathArgument doesn't translate paths in getValue(args, required)
                 Key: WFLY-2794
                 URL: https://issues.jboss.org/browse/WFLY-2794
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: 8.0.0.CR1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 8.0.0.Final


FileSystemPathArgument uses its OS-specific tab-completer to resolve absolute paths in its getValue(args) method but not in getValue(args, 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 issues at jboss.org  Wed Jan 22 12:56:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-80) Bring dependencies in-line
	with WildFly
In-Reply-To: <JIRA.12530127.1390410919000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530127.1390410919000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530127.1390410919000.7568.1390413388782@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-80:
-----------------------------------

    Fix Version/s: 2.0.1.CR1
                       (was: 2.0.0.Final)

    
> Bring dependencies in-line with WildFly
> ---------------------------------------
>
>                 Key: REMJMX-80
>                 URL: https://issues.jboss.org/browse/REMJMX-80
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.1.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 issues at jboss.org  Wed Jan 22 12:56:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-79) Release Remoting JMX
	2.0.0.Final
In-Reply-To: <JIRA.12530124.1390410446000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530124.1390410446000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530124.1390410446000.7571.1390413389052@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-79:
-----------------------------------

    Fix Version/s: 2.0.1.CR1
                       (was: 2.0.0.Final)

    
> Release Remoting JMX 2.0.0.Final
> --------------------------------
>
>                 Key: REMJMX-79
>                 URL: https://issues.jboss.org/browse/REMJMX-79
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.1.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 issues at jboss.org  Wed Jan 22 12:56:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:29 -0500 (EST)
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.7574.1390413389252@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: 2.0.1.CR1
                       (was: 2.0.0.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: 2.0.1.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 issues at jboss.org  Wed Jan 22 12:56:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:29 -0500 (EST)
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.7577.1390413389466@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: 2.0.1.CR1
                       (was: 2.0.0.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: 2.0.1.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 issues at jboss.org  Wed Jan 22 12:56:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:29 -0500 (EST)
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.7580.1390413389626@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: 2.0.1.CR1
                       (was: 2.0.0.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: 2.0.1.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 issues at jboss.org  Wed Jan 22 12:56:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:29 -0500 (EST)
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.7583.1390413389792@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: 2.0.1.CR1
                       (was: 2.0.0.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: 2.0.1.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 issues at jboss.org  Wed Jan 22 12:56:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-79) Release Remoting JMX
	2.0.0.Final
In-Reply-To: <JIRA.12530124.1390410446000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530124.1390410446000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530124.1390410446000.7586.1390413389924@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-79.
------------------------------------

    Fix Version/s: 2.0.0.Final
                       (was: 2.0.1.CR1)
       Resolution: Done

    
> Release Remoting JMX 2.0.0.Final
> --------------------------------
>
>                 Key: REMJMX-79
>                 URL: https://issues.jboss.org/browse/REMJMX-79
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.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 issues at jboss.org  Wed Jan 22 12:56:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Jan 2014 12:56:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-80) Bring dependencies in-line
	with WildFly
In-Reply-To: <JIRA.12530127.1390410919000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530127.1390410919000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530127.1390410919000.7589.1390413390028@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-80.
------------------------------------

    Fix Version/s: 2.0.0.Final
                       (was: 2.0.1.CR1)
       Resolution: Done

    
> Bring dependencies in-line with WildFly
> ---------------------------------------
>
>                 Key: REMJMX-80
>                 URL: https://issues.jboss.org/browse/REMJMX-80
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.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 issues at jboss.org  Wed Jan 22 13:30:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 13:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2794) FileSystemPathArgument
 doesn't translate paths in getValue(args, required)
In-Reply-To: <JIRA.12530131.1390412505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530131.1390412505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530131.1390412505000.7605.1390415428634@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2794:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1055898

    
> FileSystemPathArgument doesn't translate paths in getValue(args, required)
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2794
>                 URL: https://issues.jboss.org/browse/WFLY-2794
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> FileSystemPathArgument uses its OS-specific tab-completer to resolve absolute paths in its getValue(args) method but not in getValue(args, 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 issues at jboss.org  Wed Jan 22 14:06:28 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 22 Jan 2014 14:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2795) Escaped expressions are still
 expanded at runtime
In-Reply-To: <JIRA.12530143.1390417554757@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530143.1390417554757@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530143.1390417554757.7656.1390417588588@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2795:
-----------------------------------

             Summary: Escaped expressions are still expanded at runtime
                 Key: WFLY-2795
                 URL: https://issues.jboss.org/browse/WFLY-2795
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ConfigAdmin
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


In DMR expressions can be escaped with {{$$}}. Two passes are made in the [ExpressionResolverImpl|https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/ExpressionResolverImpl.java#L119]. The first pass changes {code}$${key}{code} to {code}${key}{code}. The second pass fully expands the expression.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 14:28:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 22 Jan 2014 14:28:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-211) Expose client socket binding
 config through CLI connect configs
In-Reply-To: <JIRA.12481980.1357332935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481980.1357332935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481980.1357332935000.7673.1390418908648@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-211:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)
                       (was: 8.0.0.Final)

    
> Expose client socket binding config through CLI connect configs
> ---------------------------------------------------------------
>
>                 Key: WFLY-211
>                 URL: https://issues.jboss.org/browse/WFLY-211
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 9.0.0.CR1
>
>
> Once AS7-6277 is done, continue exposing the client bind socket config to CLI 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 issues at jboss.org  Wed Jan 22 14:58:28 2014
From: issues at jboss.org (Dennis Reed (JIRA))
Date: Wed, 22 Jan 2014 14:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1116) TCPPING used with port_range
 can cause random OutOfMemoryError
In-Reply-To: <JIRA.12400589.1261045321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12400589.1261045321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12400589.1261045321000.7711.1390420708664@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Reed reopened JGRP-1116:
-------------------------------



Fixing status, which I accidentally changed during the last update to the bug.
                
> TCPPING used with port_range can cause random OutOfMemoryError
> --------------------------------------------------------------
>
>                 Key: JGRP-1116
>                 URL: https://issues.jboss.org/browse/JGRP-1116
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1 SP4
>         Environment: java 1.5, linux 2.6.9-78.0.8.EL 32/64 bit, jboss 4.2.2
>            Reporter: Sanjay Prasad
>            Assignee: Bela Ban
>             Fix For: 2.4.8
>
>         Attachments: Test.java
>
>
>   When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
>    Connection getConnection(Address dest) throws Exception {
>        Connection conn=null;
>        Socket sock;
>        synchronized(conns) {
>            conn=(Connection)conns.get(dest);
>            if(conn == null) {
>                // changed by bela Jan 18 2004: use the bind address for the client sockets as well
>                SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
>                InetAddress tmpDest=((IpAddress)dest).getIpAddress();
>                SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
>                sock=new Socket();
>                sock.bind(tmpBindAddr);
>                sock.setKeepAlive(true);
>                sock.setTcpNoDelay(tcp_nodelay);
>                if(linger > 0)
>                    sock.setSoLinger(true, linger);
>                else
>                    sock.setSoLinger(false, -1);
>                sock.connect(destAddr, sock_conn_timeout);
>               This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
>                conn=new Connection(sock, dest);
>                conn.sendLocalAddress(local_addr);
>                notifyConnectionOpened(dest);
>                // conns.put(dest, conn);
>                addConnection(dest, conn);
>                conn.init();
>                if(log.isInfoEnabled()) log.info("created socket to " + dest);
>            }
>            return conn;
>        }
>        When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
>                    len=in.readInt();
>                    if(len > buf.length)
>                        buf=new byte[len];
>                    
>                    in.readFully(buf, 0, len);
>                    updateLastAccessed();
>                    receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
>                
>       This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
>       A test program that reproduces the port collision is attached. Sample invocation below.
> bash-2.05$ java Test vlinux101
> Connected : 6789 to 6789 on try 46267
> bash-2.05$

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 15:00:29 2014
From: issues at jboss.org (Dennis Reed (JIRA))
Date: Wed, 22 Jan 2014 15:00:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1116) TCPPING used with port_range
 can cause random OutOfMemoryError
In-Reply-To: <JIRA.12400589.1261045321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12400589.1261045321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12400589.1261045321000.7714.1390420829055@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Reed resolved JGRP-1116.
-------------------------------

    Resolution: Won't Fix

    
> TCPPING used with port_range can cause random OutOfMemoryError
> --------------------------------------------------------------
>
>                 Key: JGRP-1116
>                 URL: https://issues.jboss.org/browse/JGRP-1116
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1 SP4
>         Environment: java 1.5, linux 2.6.9-78.0.8.EL 32/64 bit, jboss 4.2.2
>            Reporter: Sanjay Prasad
>            Assignee: Bela Ban
>             Fix For: 2.4.8
>
>         Attachments: Test.java
>
>
>   When TCPPING is used with port_range, i.e there are more than one possible ports to bind to, jvm may run into random OOMs. The issue is with the local port bind in the ConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks. Ping requests are send to all ports in the port range on all boxes in the cluster including the local box. When these requests try to connect to unsed ports in the range on the local box, a local bind is done in the getConnection method before a connect is called. This bind call may end up with a local port number which is the same as the unused port in the port range that the connection is being established for. This intern will allow the connect to go through even though there is no accept thread waiting on it.
>    Connection getConnection(Address dest) throws Exception {
>        Connection conn=null;
>        Socket sock;
>        synchronized(conns) {
>            conn=(Connection)conns.get(dest);
>            if(conn == null) {
>                // changed by bela Jan 18 2004: use the bind address for the client sockets as well
>                SocketAddress tmpBindAddr=new InetSocketAddress(bind_addr, 0);
>                InetAddress tmpDest=((IpAddress)dest).getIpAddress();
>                SocketAddress destAddr=new InetSocketAddress(tmpDest, ((IpAddress)dest).getPort());
>                sock=new Socket();
>                sock.bind(tmpBindAddr);
>                sock.setKeepAlive(true);
>                sock.setTcpNoDelay(tcp_nodelay);
>                if(linger > 0)
>                    sock.setSoLinger(true, linger);
>                else
>                    sock.setSoLinger(false, -1);
>                sock.connect(destAddr, sock_conn_timeout);
>               This results in a connection where the local address is sent to the other side, but there is no accept thread to read it out.
>                conn=new Connection(sock, dest);
>                conn.sendLocalAddress(local_addr);
>                notifyConnectionOpened(dest);
>                // conns.put(dest, conn);
>                addConnection(dest, conn);
>                conn.init();
>                if(log.isInfoEnabled()) log.info("created socket to " + dest);
>            }
>            return conn;
>        }
>        When this value is not read out before the reader thread is started, it is eventually read in as the lenght to allocate for reading the packet in BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks.
>                    len=in.readInt();
>                    if(len > buf.length)
>                        buf=new byte[len];
>                    
>                    in.readFully(buf, 0, len);
>                    updateLastAccessed();
>                    receive(peer_addr, buf, 0, len); // calls receiver.receive(msg)
>                
>       This in our case was allocating 1.6G of memory and sometimes would run out of memory in other parts of the program depending on how much memory was in use at that time.
>       A test program that reproduces the port collision is attached. Sample invocation below.
> bash-2.05$ java Test vlinux101
> Connected : 6789 to 6789 on try 46267
> bash-2.05$

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 15:10:28 2014
From: issues at jboss.org (Matthias Berndt (JIRA))
Date: Wed, 22 Jan 2014 15:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2695) Creating named formater
 patterns for offline servers fail
In-Reply-To: <JIRA.12528466.1388446441000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528466.1388446441000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528466.1388446441000.7720.1390421428580@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938014#comment-12938014 ] 

Matthias Berndt commented on WFLY-2695:
---------------------------------------

I think it is only a partial workaround. At the moment it is not possible to add a slave to an existiting cluster without copying logging.properties to the new slave.
                
> Creating named formater patterns for offline servers fail
> ---------------------------------------------------------
>
>                 Key: WFLY-2695
>                 URL: https://issues.jboss.org/browse/WFLY-2695
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.CR1
>         Environment: any domain configuration
>            Reporter: Matthias Berndt
>            Assignee: James Perkins
>
> After adding and attaching a named formatter to an offline server starting the server fails due to an invalid logging configuration.
> server-one fails with:
> {{
> [Server:server-one] 00:08:00,214 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> [Server:server-one]     ("subsystem" => "logging"),
> [Server:server-one]     ("console-handler" => "CONSOLE")
> [Server:server-one] ]): java.lang.IllegalArgumentException: Formatter "TESTPATTERN" is not found
> }}
> I assume logging.properties is written too late in LoggingOperations.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 issues at jboss.org  Wed Jan 22 15:48:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 15:48:28 -0500 (EST)
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.7751.1390423708661@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-140.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Final
                       (was: JavaEE 7 Spec APIs 1.0.0.Beta2)
       Resolution: Done


https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/jacc/jboss-jacc-api_1.5_spec/1.0.0.Final/

has been released
                
> 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: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Final
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> 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 issues at jboss.org  Wed Jan 22 16:04:28 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 22 Jan 2014 16:04:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2796) Update JSF based on
 jsf-impl-2.2.5-jbossorg-2
In-Reply-To: <JIRA.12530150.1390424566765@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530150.1390424566765@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530150.1390424566765.7766.1390424668557@jira02.app.mwc.hst.phx2.redhat.com>

Farah Juma created WFLY-2796:
--------------------------------

             Summary: Update JSF based on jsf-impl-2.2.5-jbossorg-2
                 Key: WFLY-2796
                 URL: https://issues.jboss.org/browse/WFLY-2796
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: 8.0.0.CR1
            Reporter: Farah Juma
            Assignee: Farah Juma
             Fix For: 8.0.0.Final


Brian Leathem has found that the following trivial issue that affects Mojarra 2.2.5 has somewhat profound consequences for RichFaces 5:

https://java.net/jira/browse/JAVASERVERFACES-3151

The fix for this issue is already available here:
https://java.net/jira/secure/attachment/53117/changebundle.txt

He has requested that this small fix be applied to the Mojarra that ships with WildFly in time for WildFly 8.0.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 issues at jboss.org  Wed Jan 22 16:04:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 16:04:28 -0500 (EST)
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.7768.1390424668646@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938023#comment-12938023 ] 

Shelly McGowan edited comment on JBEE-140 at 1/22/14 4:03 PM:
--------------------------------------------------------------

https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/auth/message/jboss-jaspi-api_1.1_spec/1.0.0.Final/
has been released
                
      was (Author: shelly.mcgowan):
    https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/jacc/jboss-jacc-api_1.5_spec/1.0.0.Final/

has been released
                  
> 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: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Final
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> 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 issues at jboss.org  Wed Jan 22 16:06:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 16:06:28 -0500 (EST)
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.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501330.1379963000000.7772.1390424788646@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-141.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Final
                       (was: JavaEE 7 Spec APIs 1.0.0.CR1)
       Resolution: Done


https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/jacc/jboss-jacc-api_1.5_spec/1.0.0.Final/

has been released.
                
> 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
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Final
>
>
> 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 issues at jboss.org  Wed Jan 22 17:30:28 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 22 Jan 2014 17:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2695) Creating named formater
 patterns for offline servers fail
In-Reply-To: <JIRA.12528466.1388446441000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528466.1388446441000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528466.1388446441000.7924.1390429828547@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938054#comment-12938054 ] 

James Perkins commented on WFLY-2695:
-------------------------------------

That would be a different issue really. I suppose we could group them, but the issue here was the order in which the server attempted to configure the log manager.
                
> Creating named formater patterns for offline servers fail
> ---------------------------------------------------------
>
>                 Key: WFLY-2695
>                 URL: https://issues.jboss.org/browse/WFLY-2695
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 8.0.0.CR1
>         Environment: any domain configuration
>            Reporter: Matthias Berndt
>            Assignee: James Perkins
>
> After adding and attaching a named formatter to an offline server starting the server fails due to an invalid logging configuration.
> server-one fails with:
> {{
> [Server:server-one] 00:08:00,214 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> [Server:server-one]     ("subsystem" => "logging"),
> [Server:server-one]     ("console-handler" => "CONSOLE")
> [Server:server-one] ]): java.lang.IllegalArgumentException: Formatter "TESTPATTERN" is not found
> }}
> I assume logging.properties is written too late in LoggingOperations.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 issues at jboss.org  Wed Jan 22 17:38:28 2014
From: issues at jboss.org (yangju (JIRA))
Date: Wed, 22 Jan 2014 17:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.7932.1390430308972@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938055#comment-12938055 ] 

yangju commented on WFLY-2762:
------------------------------

org.jboss.weld.nonPortableMode=true does not seem working anymore in CR1. I still got error:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.jboss.solder.servlet.http.CookieParamProducer.request
  at org.jboss.solder.servlet.http.CookieParamProducer.request(CookieParamProducer.java:0)
  Possible dependencies: 
  - WELD|AbstractSyntheticBean|epen-login-1.4.30-SNAPSHOT.war/WEB-INF/lib/solder-impl-3.2.0.Final.jar|HttpServletRequest,
  - Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()]

	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:369)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 17:40:28 2014
From: issues at jboss.org (yangju (JIRA))
Date: Wed, 22 Jan 2014 17:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1356) kitchensink quickstart fails
 against WildFly
In-Reply-To: <JIRA.12491980.1368716524000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491980.1368716524000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491980.1368716524000.7937.1390430428935@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938056#comment-12938056 ] 

yangju commented on WFLY-1356:
------------------------------

Even with org.jboss.weld.nonPortableMode set to true, still got errors when deploying application with Solder library (Solder-impl.3.2.0.Final and 3.1.0.Final):

Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default
  at injection point [BackedAnnotatedField] @Inject private org.jboss.solder.servlet.http.CookieParamProducer.request
  at org.jboss.solder.servlet.http.CookieParamProducer.request(CookieParamProducer.java:0)
  Possible dependencies: 
  - WELD|AbstractSyntheticBean|epen-login-1.4.30-SNAPSHOT.war/WEB-INF/lib/solder-impl-3.2.0.Final.jar|HttpServletRequest,
  - Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[BackedAnnotatedMethod] @Produces @Typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()]

	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:369)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
                
> kitchensink quickstart fails against WildFly
> --------------------------------------------
>
>                 Key: WFLY-1356
>                 URL: https://issues.jboss.org/browse/WFLY-1356
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> I've been updating the quickstarts to run them against WildFly. The branch is here https://github.com/jaikiran/quickstart/commits/wildfly-upgrade.
> The kitchensink quickstart application https://github.com/jaikiran/quickstart/tree/wildfly-upgrade/kitchensink fails to deploy with the following logs:
> {code}
> 20:28:08,730 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016002: Processing weld deployment jboss-as-kitchensink.war
> 20:28:08,734 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-4) JNDI bindings for session bean named MemberRegistration in deployment unit deployment "jboss-as-kitchensink.war" are as follows:
> 	java:global/jboss-as-kitchensink/MemberRegistration!org.jboss.as.quickstarts.kitchensink.service.MemberRegistration
> 	java:app/jboss-as-kitchensink/MemberRegistration!org.jboss.as.quickstarts.kitchensink.service.MemberRegistration
> 	java:module/MemberRegistration!org.jboss.as.quickstarts.kitchensink.service.MemberRegistration
> 	java:global/jboss-as-kitchensink/MemberRegistration
> 	java:app/jboss-as-kitchensink/MemberRegistration
> 	java:module/MemberRegistration
> 20:28:08,862 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: jboss-as-kitchensink.war
> 20:28:08,895 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 2.0.0 (CR4)
> 20:28:08,916 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment jboss-as-kitchensink.war
> 20:28:08,917 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 58) JBAS011402: Starting Persistence Unit Service 'jboss-as-kitchensink.war#primary'
> 20:28:09,029 INFO  [org.hibernate.annotations.common.Version] (ServerService Thread Pool -- 58) HCANN000001: Hibernate Commons Annotations {4.0.1.Final}
> 20:28:09,034 INFO  [org.hibernate.Version] (ServerService Thread Pool -- 58) HHH000412: Hibernate Core {4.2.0.Final}
> 20:28:09,036 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 58) HHH000206: hibernate.properties not found
> 20:28:09,038 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 58) HHH000021: Bytecode provider name : javassist
> 20:28:09,207 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-3) Legacy deployment metadata provided by the integrator. Certain functionality will not be available.
> 20:28:09,223 INFO  [org.hibernate.ejb.Ejb3Configuration] (ServerService Thread Pool -- 58) HHH000204: Processing PersistenceUnitInfo [
> 	name: primary
> 	...]
> 20:28:09,353 INFO  [org.hibernate.service.jdbc.connections.internal.ConnectionProviderInitiator] (ServerService Thread Pool -- 58) HHH000130: Instantiating explicit connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider
> 20:28:09,517 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 58) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
> 20:28:09,520 WARN  [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 58) HHH000431: Unable to determine H2 database version, certain features may not work
> 20:28:09,522 INFO  [org.hibernate.engine.jdbc.internal.LobCreatorBuilder] (ServerService Thread Pool -- 58) HHH000423: Disabling contextual LOB creation as JDBC driver reported JDBC version [3] less than 4
> 20:28:09,529 INFO  [org.hibernate.engine.transaction.internal.TransactionFactoryInitiator] (ServerService Thread Pool -- 58) HHH000268: Transaction strategy: org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory
> 20:28:09,532 INFO  [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 58) HHH000397: Using ASTQueryTranslatorFactory
> 20:28:09,559 INFO  [org.hibernate.validator.internal.util.Version] (ServerService Thread Pool -- 58) HV000001: Hibernate Validator 4.3.1.Final
> 20:28:09,765 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000227: Running hbm2ddl schema export
> 20:28:09,772 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000389: Unsuccessful: drop sequence hibernate_sequence
> 20:28:09,772 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:
> drop sequence hibernate_sequence [90036-168]
> 20:28:09,775 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000230: Schema export complete
> 20:28:10,049 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [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_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]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService.validator]
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
> 	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
> 	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
> 	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:70)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
> 	... 3 more
> 20:28:10,058 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jboss-as-kitchensink.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService.validator]"}}
> 20:28:10,063 ERROR [org.jboss.as.server] (management-handler-thread - 1) JBAS015870: Deploy of deployment "jboss-as-kitchensink.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService.validator]"}}
> 20:28:10,069 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 58) JBAS011403: Stopping Persistence Unit Service 'jboss-as-kitchensink.war#primary'
> 20:28:10,070 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000227: Running hbm2ddl schema export
> 20:28:10,072 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment jboss-as-kitchensink.war
> 20:28:10,074 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000230: Schema export complete
> 20:28:10,092 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/KitchensinkQuickstartDS]
> 20:28:10,101 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment jboss-as-kitchensink.war (runtime-name: jboss-as-kitchensink.war) in 39ms
> 20:28:10,107 INFO  [org.jboss.as.controller] (management-handler-thread - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."jboss-as-kitchensink.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator, service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".WeldInstantiator, JBAS014799: ... and 5 more ] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator, JBAS014799: ... and 3 more ] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.VIEW."org.jboss.as.quickstarts.kitchensink.service.MemberRegistration".LOCAL (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START, JBAS014799: ... and 3 more ] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.persistenceunit."jboss-as-kitchensink.war#primary" (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START, service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START, JBAS014799: ... and 6 more ] 
>       service jboss.undertow.deployment.default-host./jboss-as-kitchensink (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink] 
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService
> {code}
> P.S: I haven't yet investigated the issue and am just guessing it might be related to Weld, based on the exception stacktrace. At this point, I'm just filing JIRAs so that we investigate these before our release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 17:40:29 2014
From: issues at jboss.org (yangju (JIRA))
Date: Wed, 22 Jan 2014 17:40:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1356) kitchensink quickstart fails
 against WildFly
In-Reply-To: <JIRA.12491980.1368716524000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491980.1368716524000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491980.1368716524000.7942.1390430429225@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938058#comment-12938058 ] 

yangju commented on WFLY-1356:
------------------------------

Above error was from CR1
                
> kitchensink quickstart fails against WildFly
> --------------------------------------------
>
>                 Key: WFLY-1356
>                 URL: https://issues.jboss.org/browse/WFLY-1356
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> I've been updating the quickstarts to run them against WildFly. The branch is here https://github.com/jaikiran/quickstart/commits/wildfly-upgrade.
> The kitchensink quickstart application https://github.com/jaikiran/quickstart/tree/wildfly-upgrade/kitchensink fails to deploy with the following logs:
> {code}
> 20:28:08,730 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016002: Processing weld deployment jboss-as-kitchensink.war
> 20:28:08,734 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-4) JNDI bindings for session bean named MemberRegistration in deployment unit deployment "jboss-as-kitchensink.war" are as follows:
> 	java:global/jboss-as-kitchensink/MemberRegistration!org.jboss.as.quickstarts.kitchensink.service.MemberRegistration
> 	java:app/jboss-as-kitchensink/MemberRegistration!org.jboss.as.quickstarts.kitchensink.service.MemberRegistration
> 	java:module/MemberRegistration!org.jboss.as.quickstarts.kitchensink.service.MemberRegistration
> 	java:global/jboss-as-kitchensink/MemberRegistration
> 	java:app/jboss-as-kitchensink/MemberRegistration
> 	java:module/MemberRegistration
> 20:28:08,862 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: jboss-as-kitchensink.war
> 20:28:08,895 INFO  [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 2.0.0 (CR4)
> 20:28:08,916 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment jboss-as-kitchensink.war
> 20:28:08,917 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 58) JBAS011402: Starting Persistence Unit Service 'jboss-as-kitchensink.war#primary'
> 20:28:09,029 INFO  [org.hibernate.annotations.common.Version] (ServerService Thread Pool -- 58) HCANN000001: Hibernate Commons Annotations {4.0.1.Final}
> 20:28:09,034 INFO  [org.hibernate.Version] (ServerService Thread Pool -- 58) HHH000412: Hibernate Core {4.2.0.Final}
> 20:28:09,036 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 58) HHH000206: hibernate.properties not found
> 20:28:09,038 INFO  [org.hibernate.cfg.Environment] (ServerService Thread Pool -- 58) HHH000021: Bytecode provider name : javassist
> 20:28:09,207 WARN  [org.jboss.weld.Bootstrap] (MSC service thread 1-3) Legacy deployment metadata provided by the integrator. Certain functionality will not be available.
> 20:28:09,223 INFO  [org.hibernate.ejb.Ejb3Configuration] (ServerService Thread Pool -- 58) HHH000204: Processing PersistenceUnitInfo [
> 	name: primary
> 	...]
> 20:28:09,353 INFO  [org.hibernate.service.jdbc.connections.internal.ConnectionProviderInitiator] (ServerService Thread Pool -- 58) HHH000130: Instantiating explicit connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider
> 20:28:09,517 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 58) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
> 20:28:09,520 WARN  [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 58) HHH000431: Unable to determine H2 database version, certain features may not work
> 20:28:09,522 INFO  [org.hibernate.engine.jdbc.internal.LobCreatorBuilder] (ServerService Thread Pool -- 58) HHH000423: Disabling contextual LOB creation as JDBC driver reported JDBC version [3] less than 4
> 20:28:09,529 INFO  [org.hibernate.engine.transaction.internal.TransactionFactoryInitiator] (ServerService Thread Pool -- 58) HHH000268: Transaction strategy: org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory
> 20:28:09,532 INFO  [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 58) HHH000397: Using ASTQueryTranslatorFactory
> 20:28:09,559 INFO  [org.hibernate.validator.internal.util.Version] (ServerService Thread Pool -- 58) HV000001: Hibernate Validator 4.3.1.Final
> 20:28:09,765 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000227: Running hbm2ddl schema export
> 20:28:09,772 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000389: Unsuccessful: drop sequence hibernate_sequence
> 20:28:09,772 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:
> drop sequence hibernate_sequence [90036-168]
> 20:28:09,775 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000230: Schema export complete
> 20:28:10,049 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [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_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]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService.validator]
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:325)
> 	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:177)
> 	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:208)
> 	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:519)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:70)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
> 	... 3 more
> 20:28:10,058 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jboss-as-kitchensink.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService.validator]"}}
> 20:28:10,063 ERROR [org.jboss.as.server] (management-handler-thread - 1) JBAS015870: Deploy of deployment "jboss-as-kitchensink.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-as-kitchensink.war\".WeldStartService: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[BackedAnnotatedField] @Inject private org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService.validator]"}}
> 20:28:10,069 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 58) JBAS011403: Stopping Persistence Unit Service 'jboss-as-kitchensink.war#primary'
> 20:28:10,070 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000227: Running hbm2ddl schema export
> 20:28:10,072 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment jboss-as-kitchensink.war
> 20:28:10,074 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 58) HHH000230: Schema export complete
> 20:28:10,092 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/KitchensinkQuickstartDS]
> 20:28:10,101 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment jboss-as-kitchensink.war (runtime-name: jboss-as-kitchensink.war) in 39ms
> 20:28:10,107 INFO  [org.jboss.as.controller] (management-handler-thread - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."jboss-as-kitchensink.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator, service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".WeldInstantiator, JBAS014799: ... and 5 more ] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".WeldInstantiator, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator, JBAS014799: ... and 3 more ] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.VIEW."org.jboss.as.quickstarts.kitchensink.service.MemberRegistration".LOCAL (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.faces.webapp.FacetTag".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".CREATE (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService, service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START, JBAS014799: ... and 3 more ] 
>       service jboss.deployment.unit."jboss-as-kitchensink.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component.MemberRegistration.START] 
>       service jboss.persistenceunit."jboss-as-kitchensink.war#primary" (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".component."com.sun.faces.config.ConfigureListener".START, service jboss.undertow.deployment.default-host./jboss-as-kitchensink, service jboss.deployment.unit."jboss-as-kitchensink.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."jboss-as-kitchensink.war".component."org.jboss.weld.servlet.WeldListener".START, JBAS014799: ... and 6 more ] 
>       service jboss.undertow.deployment.default-host./jboss-as-kitchensink (missing) dependents: [service jboss.deployment.unit."jboss-as-kitchensink.war".deploymentCompleteService] 
>       service jboss.undertow.deployment.default-host./jboss-as-kitchensink.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-host./jboss-as-kitchensink] 
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."jboss-as-kitchensink.war".WeldStartService
> {code}
> P.S: I haven't yet investigated the issue and am just guessing it might be related to Weld, based on the exception stacktrace. At this point, I'm just filing JIRAs so that we investigate these before our release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 17:46:29 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 22 Jan 2014 17:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-91) Allow the size rotating
 handlers to append a defined suffix when rotating
In-Reply-To: <JIRA.12530164.1390430759666@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530164.1390430759666@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530164.1390430759666.7956.1390430789116@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created LOGMGR-91:
-----------------------------------

             Summary: Allow the size rotating handlers to append a defined suffix when rotating
                 Key: LOGMGR-91
                 URL: https://issues.jboss.org/browse/LOGMGR-91
             Project: JBoss Log Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


Currently when the {{SizeRotatingFileHandler}} rotates a digit is appended to the file name. Support the ability to change the value appended to the file name to a date. Previously rotated files would not be moved as they are currently. e.g. log.1 would not move to log.2 when log is rotated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 22 17:52:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 17:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.7970.1390431148589@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938063#comment-12938063 ] 

Shelly McGowan commented on JBEE-133:
-------------------------------------

https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/el/jboss-el-api_3.0_spec/1.0.0.Final/

has been released
                
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.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 issues at jboss.org  Wed Jan 22 18:20:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jan 2014 18:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775547@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775547@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775547.7990.1390432828717@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created JBMETA-371:
---------------------------------------

             Summary: DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
                 Key: JBMETA-371
                 URL: https://issues.jboss.org/browse/JBMETA-371
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common
    Affects Versions: 7.0.4
            Reporter: Brian Stansberry


The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between ${ and } have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Wed Jan 22 18:22:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jan 2014 18:22:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.7993.1390432948623@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBMETA-371:
------------------------------------

    Description: 
The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".

  was:
The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between ${ and } have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".


    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Wed Jan 22 21:30:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 22 Jan 2014 21:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.8053.1390444228667@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBMETA-371:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056799

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Wed Jan 22 22:16:29 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 22 Jan 2014 22:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-414) Queries do not work with
 chained accessors as arguments
In-Reply-To: <JIRA.12530172.1390446870769@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530172.1390446870769@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530172.1390446870769.8079.1390446989257@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-414:
-------------------------------------

             Summary: Queries do not work with chained accessors as arguments
                 Key: DROOLS-414
                 URL: https://issues.jboss.org/browse/DROOLS-414
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


When processing a query CE that uses chained property accessors:

when
  $x : Foo()
  myQuery( $x.bar ; ) 
then

the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will 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 issues at jboss.org  Wed Jan 22 22:34:28 2014
From: issues at jboss.org (xiang yingbing (JIRA))
Date: Wed, 22 Jan 2014 22:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989749@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989749@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989749.8082.1390448068610@jira02.app.mwc.hst.phx2.redhat.com>

xiang yingbing created WFLY-2797:
------------------------------------

             Summary: Update hibernate to 4.3.1 or above according to HHH-8756
                 Key: WFLY-2797
                 URL: https://issues.jboss.org/browse/WFLY-2797
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
    Affects Versions: 8.0.0.CR1
         Environment: 8.0.0.CR1
            Reporter: xiang yingbing
            Assignee: David Lloyd


1. The bug description:
    https://community.jboss.org/message/851147#851147

Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query



2. This bug is fixed since hibernate-4.3.1:
https://hibernate.atlassian.net/browse/HHH-8756


So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.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 issues at jboss.org  Wed Jan 22 22:52:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 22:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2792) Upgrade Java EE 7 Spec APIs
 to .Final versions
In-Reply-To: <JIRA.12530122.1390409593000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530122.1390409593000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530122.1390409593000.8096.1390449148824@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated WFLY-2792:
---------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5752

    
> Upgrade Java EE 7 Spec APIs to .Final versions
> ----------------------------------------------
>
>                 Key: WFLY-2792
>                 URL: https://issues.jboss.org/browse/WFLY-2792
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.Final
>
>
> Specifically:
> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.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 issues at jboss.org  Wed Jan 22 22:56:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 22:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.8107.1390449388600@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938083#comment-12938083 ] 

Shelly McGowan commented on JBEE-133:
-------------------------------------

WildFly 8.0.0.Final includes the EL API and Impl from GlassFish.  These APIs are also included in WildFly for access to the org.jboss.el.cache.FactoryFinderCache class used in WildFly.  Separation of EL API and Impl is targeted for WildFly.NEXT.  Considering this resolved for now.
                
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.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 issues at jboss.org  Wed Jan 22 22:56:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 22:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.8109.1390449388725@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-133.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Final
                       (was: JavaEE 7 Spec APIs 1.0.0.CR1)
       Resolution: Done

    
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.0.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 issues at jboss.org  Wed Jan 22 23:06:28 2014
From: issues at jboss.org (xiang yingbing (JIRA))
Date: Wed, 22 Jan 2014 23:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.8114.1390449988537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

xiang yingbing updated WFLY-2797:
---------------------------------

    Description: 
1. The bug description:
    https://community.jboss.org/message/851147#851147

Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query

2. This bug is fixed since hibernate-4.3.1:
https://hibernate.atlassian.net/browse/HHH-8756

So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.

NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.3.0

  was:
1. The bug description:
    https://community.jboss.org/message/851147#851147

Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query



2. This bug is fixed since hibernate-4.3.1:
https://hibernate.atlassian.net/browse/HHH-8756


So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.


    
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: David Lloyd
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Wed Jan 22 23:10:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jan 2014 23:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-121) Tracker JIRA for APIs required
 by the Java EE 7 Platform Specification
In-Reply-To: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485867.1362012695000.8118.1390450228661@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-121.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Final
                       (was: JavaEE 7 Spec APIs 1.0.0.CR1)
       Resolution: Done

    
> Tracker JIRA for APIs required by the Java EE 7 Platform Specification
> ----------------------------------------------------------------------
>
>                 Key: JBEE-121
>                 URL: https://issues.jboss.org/browse/JBEE-121
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.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 issues at jboss.org  Thu Jan 23 03:10:28 2014
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Thu, 23 Jan 2014 03:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.8209.1390464628790@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated WFLY-2641:
---------------------------------

    Priority: Blocker  (was: Critical)


Raised to blocker. This is affecting the WildFly test suite and at least two integration projects that I know of. 
                
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Aslak Knutsen
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Thu Jan 23 03:34:29 2014
From: issues at jboss.org (Andre Dietisheim (JIRA))
Date: Thu, 23 Jan 2014 03:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-705) Implement a User Agent and
 Remote Address Filter for the HTTP Management Interface
In-Reply-To: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450792.1319827535000.8276.1390466069537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andre Dietisheim resolved WFLY-705.
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: Awaiting Volunteers)
       Resolution: Done

    
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-705
>                 URL: https://issues.jboss.org/browse/WFLY-705
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Andre Dietisheim
>             Fix For: 8.0.0.CR1
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 03:36:29 2014
From: issues at jboss.org (Matus Abaffy (JIRA))
Date: Thu, 23 Jan 2014 03:36:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.8286.1390466189743@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938120#comment-12938120 ] 

Matus Abaffy commented on WFLY-2387:
------------------------------------

bq. Is there a CDI spec section that states this use case specifically?
Actually, CDI spec doesn't mention entity listeners at all. Java EE 7 spec (EE.5.2.5 Annotations and Injection, Table EE.5-1) requires that entity listeners support (by default) also CDI injection. (Even if the entity listener itself doesn't inject an EntityManager, it can inject another bean which injects an EntityManager via CDI, which is completely legal.)
                
> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Final
>
>         Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 03:36:31 2014
From: issues at jboss.org (Andre Dietisheim (JIRA))
Date: Thu, 23 Jan 2014 03:36:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-705) Implement a User Agent and
 Remote Address Filter for the HTTP Management Interface
In-Reply-To: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450792.1319827535000.8309.1390466191169@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938122#comment-12938122 ] 

Andre Dietisheim commented on WFLY-705:
---------------------------------------

[~brian.stansberry] if I read you right this issue covers only the untertow filters, the configuration options for the management service (HttpManagementResourceDefinition) will get implemented against WFLY-2635, right?
                
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-705
>                 URL: https://issues.jboss.org/browse/WFLY-705
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Andre Dietisheim
>             Fix For: 8.0.0.CR1
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 03:38:28 2014
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 23 Jan 2014 03:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.8314.1390466308823@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938123#comment-12938123 ] 

Carlo de Wolf commented on JBMETA-371:
--------------------------------------

It looks to me that you're feeding it something that is outside of its design. Don't do that. :-)
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Thu Jan 23 03:52:28 2014
From: issues at jboss.org (Falko M. (JIRA))
Date: Thu, 23 Jan 2014 03:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-983) Arquillian managed container
 does not allow logging configuration
In-Reply-To: <JIRA.12477899.1351189051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477899.1351189051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477899.1351189051000.8330.1390467148808@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938129#comment-12938129 ] 

Falko M. commented on WFLY-983:
-------------------------------

Shouldn't this issue be assigned to the ARQ project instead of WFLY?
                
> Arquillian managed container does not allow logging configuration
> -----------------------------------------------------------------
>
>                 Key: WFLY-983
>                 URL: https://issues.jboss.org/browse/WFLY-983
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Karel Piwko
>            Assignee: Ondrej Zizka
>            Priority: Minor
>
> Config path is hardcoded in ManagedDeployableContainer.
> It is not possible to set the "logging.configuration" and the "org.jboss.boot.log.file" relative to the "jboss.server.base.dir" ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 03:56:30 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 23 Jan 2014 03:56:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.8356.1390467390651@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFLY-880:
-----------------------------------

    Assignee: Alexey Loubyansky  (was: Richard Opalka)

    
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 03:58:29 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 23 Jan 2014 03:58:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-311) Remove
 ServiceReferenceHandler & VirtualFileAdaptor from jboss-metadata-common
 once switchboard is in place
In-Reply-To: <JIRA.12423774.1289555736000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12423774.1289555736000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12423774.1289555736000.8382.1390467509072@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned JBMETA-311:
-------------------------------------

    Assignee: Alessio Soldano  (was: Richard Opalka)

    
> Remove ServiceReferenceHandler & VirtualFileAdaptor from jboss-metadata-common once switchboard is in place
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-311
>                 URL: https://issues.jboss.org/browse/JBMETA-311
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: common
>            Reporter: Richard Opalka
>            Assignee: Alessio Soldano
>             Fix For: jboss-metadata-common-2.0.0-alpha-25
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 04:10:29 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Thu, 23 Jan 2014 04:10:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-311) Remove
 ServiceReferenceHandler & VirtualFileAdaptor from jboss-metadata-common
 once switchboard is in place
In-Reply-To: <JIRA.12423774.1289555736000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12423774.1289555736000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12423774.1289555736000.8423.1390468229165@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938141#comment-12938141 ] 

Alessio Soldano commented on JBMETA-311:
----------------------------------------

Richard, please provide a meaningful description for this jira and why it was needed. I'm completely out-of-context, being this a 3+ yrs old thing.
                
> Remove ServiceReferenceHandler & VirtualFileAdaptor from jboss-metadata-common once switchboard is in place
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-311
>                 URL: https://issues.jboss.org/browse/JBMETA-311
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: common
>            Reporter: Richard Opalka
>            Assignee: Alessio Soldano
>             Fix For: jboss-metadata-common-2.0.0-alpha-25
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 04:14:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 23 Jan 2014 04:14:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.8433.1390468468986@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938142#comment-12938142 ] 

Stuart Douglas commented on WFLY-2778:
--------------------------------------

The latest nightly should have the potential fix included: https://ci.jboss.org/hudson/job/WildFly-latest-master/ 
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 04:42:28 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 23 Jan 2014 04:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2798) Operation description does
 not include runtime-only metadata
In-Reply-To: <JIRA.12530183.1390470053078@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530183.1390470053078@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530183.1390470053078.8501.1390470148576@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2798:
---------------------------------

             Summary: Operation description does not include runtime-only metadata
                 Key: WFLY-2798
                 URL: https://issues.jboss.org/browse/WFLY-2798
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Jeff Mesnil
            Assignee: Brian Stansberry


Operation can be defined as runtime-only by setting the OperationEntry.Flag.RUNTIME_ONLY flag on its definition.

However, the :read-operation-description does not return this flag when it is set.

For example the global read-attribute operation is flagged as runtime only but calling /subsystem=mail:read-operation-description(name=read-attribute) will not show that the operation is runtime only:

{noformat}
/subsystem=mail:read-operation-description(name=read-attribute)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "read-attribute",
        "description" => "Gets the value of an attribute for the selected resource",
        "request-properties" => {
            ...
        },
        "reply-properties" => {
            "type" => OBJECT,
            "description" => "The value of the attribute. The type will be that of the attribute found"
        },
        "read-only" => true
    }
}
{noformat}

Note that the read-only flag is correctly returned.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 04:44:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Thu, 23 Jan 2014 04:44:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.8508.1390470269452@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938156#comment-12938156 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Already checking it out, I'll get back to it soon. 
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 04:46:29 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 23 Jan 2014 04:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2798) Operation description does
 not include runtime-only metadata
In-Reply-To: <JIRA.12530183.1390470053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530183.1390470053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530183.1390470053000.8524.1390470389758@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-2798:
---------------------------------

    Assignee: Jeff Mesnil  (was: Brian Stansberry)

    
> Operation description does not include runtime-only metadata
> ------------------------------------------------------------
>
>                 Key: WFLY-2798
>                 URL: https://issues.jboss.org/browse/WFLY-2798
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> Operation can be defined as runtime-only by setting the OperationEntry.Flag.RUNTIME_ONLY flag on its definition.
> However, the :read-operation-description does not return this flag when it is set.
> For example the global read-attribute operation is flagged as runtime only but calling /subsystem=mail:read-operation-description(name=read-attribute) will not show that the operation is runtime only:
> {noformat}
> /subsystem=mail:read-operation-description(name=read-attribute)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "read-attribute",
>         "description" => "Gets the value of an attribute for the selected resource",
>         "request-properties" => {
>             ...
>         },
>         "reply-properties" => {
>             "type" => OBJECT,
>             "description" => "The value of the attribute. The type will be that of the attribute found"
>         },
>         "read-only" => true
>     }
> }
> {noformat}
> Note that the read-only flag is correctly returned.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 05:06:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 23 Jan 2014 05:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2799) Drop
 SystemMemoryUsageLoadMetric from mod_cluster subsystem
In-Reply-To: <JIRA.12530187.1390471579770@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530187.1390471579770@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530187.1390471579770.8563.1390471588649@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2799:
------------------------------------

             Summary: Drop SystemMemoryUsageLoadMetric from mod_cluster subsystem
                 Key: WFLY-2799
                 URL: https://issues.jboss.org/browse/WFLY-2799
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 8.0.0.Final


See MODCLUSTER-288.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 05:16:30 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 23 Jan 2014 05:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2798) Operation description does
 not include runtime-only metadata
In-Reply-To: <JIRA.12530183.1390470053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530183.1390470053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530183.1390470053000.8580.1390472190331@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2798:
------------------------------

    Priority: Minor  (was: Major)

    
> Operation description does not include runtime-only metadata
> ------------------------------------------------------------
>
>                 Key: WFLY-2798
>                 URL: https://issues.jboss.org/browse/WFLY-2798
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Operation can be defined as runtime-only by setting the OperationEntry.Flag.RUNTIME_ONLY flag on its definition.
> However, the :read-operation-description does not return this flag when it is set.
> For example the global read-attribute operation is flagged as runtime only but calling /subsystem=mail:read-operation-description(name=read-attribute) will not show that the operation is runtime only:
> {noformat}
> /subsystem=mail:read-operation-description(name=read-attribute)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "read-attribute",
>         "description" => "Gets the value of an attribute for the selected resource",
>         "request-properties" => {
>             ...
>         },
>         "reply-properties" => {
>             "type" => OBJECT,
>             "description" => "The value of the attribute. The type will be that of the attribute found"
>         },
>         "read-only" => true
>     }
> }
> {noformat}
> Note that the read-only flag is correctly returned.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 05:16:30 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 23 Jan 2014 05:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2798) Operation description does
 not include runtime-only metadata
In-Reply-To: <JIRA.12530183.1390470053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530183.1390470053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530183.1390470053000.8582.1390472190406@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2798:
------------------------------

    Issue Type: Enhancement  (was: Feature Request)

    
> Operation description does not include runtime-only metadata
> ------------------------------------------------------------
>
>                 Key: WFLY-2798
>                 URL: https://issues.jboss.org/browse/WFLY-2798
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> Operation can be defined as runtime-only by setting the OperationEntry.Flag.RUNTIME_ONLY flag on its definition.
> However, the :read-operation-description does not return this flag when it is set.
> For example the global read-attribute operation is flagged as runtime only but calling /subsystem=mail:read-operation-description(name=read-attribute) will not show that the operation is runtime only:
> {noformat}
> /subsystem=mail:read-operation-description(name=read-attribute)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "read-attribute",
>         "description" => "Gets the value of an attribute for the selected resource",
>         "request-properties" => {
>             ...
>         },
>         "reply-properties" => {
>             "type" => OBJECT,
>             "description" => "The value of the attribute. The type will be that of the attribute found"
>         },
>         "read-only" => true
>     }
> }
> {noformat}
> Note that the read-only flag is correctly returned.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 05:30:28 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 23 Jan 2014 05:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-311) Remove
 ServiceReferenceHandler & VirtualFileAdaptor from jboss-metadata-common
 once switchboard is in place
In-Reply-To: <JIRA.12423774.1289555736000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12423774.1289555736000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12423774.1289555736000.8626.1390473028623@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938175#comment-12938175 ] 

Richard Opalka commented on JBMETA-311:
---------------------------------------

I'm out-of-context too TBH :(
It had something to do with dependency cleanup AFAIRC.
But if you're fine with these JBMETA -> WS dependencies,
you can close this JIRA.
                
> Remove ServiceReferenceHandler & VirtualFileAdaptor from jboss-metadata-common once switchboard is in place
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-311
>                 URL: https://issues.jboss.org/browse/JBMETA-311
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: common
>            Reporter: Richard Opalka
>            Assignee: Alessio Soldano
>             Fix For: jboss-metadata-common-2.0.0-alpha-25
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 05:38:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 05:38:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2616) SEVERE is not an available
 logging level in the CLI
In-Reply-To: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527159.1386289598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527159.1386289598000.8659.1390473509655@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938180#comment-12938180 ] 

RH Bugzilla Integration commented on WFLY-2616:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1038862|https://bugzilla.redhat.com/show_bug.cgi?id=1038862] from ON_QA to VERIFIED
                
> SEVERE is not an available logging level in the CLI
> ---------------------------------------------------
>
>                 Key: WFLY-2616
>                 URL: https://issues.jboss.org/browse/WFLY-2616
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Kyle Lape
>            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 issues at jboss.org  Thu Jan 23 05:42:29 2014
From: issues at jboss.org (Ramil Israfilov (JIRA))
Date: Thu, 23 Jan 2014 05:42:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.8672.1390473749219@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938183#comment-12938183 ] 

Ramil Israfilov commented on WFLY-880:
--------------------------------------

so far I'm trying to use workaround by calling /deployment=*:read-resource.
is outcome => success means that ear/war deployed successfully ?
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 06:26:29 2014
From: issues at jboss.org (Eric van der Maarel (JIRA))
Date: Thu, 23 Jan 2014 06:26:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2800) Re-invoking
 InterceptorContext.proceed() throws CannoteProceedException
In-Reply-To: <JIRA.12530192.1390476344718@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530192.1390476344718@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530192.1390476344718.8888.1390476389042@jira02.app.mwc.hst.phx2.redhat.com>

Eric van der Maarel created WFLY-2800:
-----------------------------------------

             Summary: Re-invoking InterceptorContext.proceed() throws CannoteProceedException
                 Key: WFLY-2800
                 URL: https://issues.jboss.org/browse/WFLY-2800
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBoss AS7 7.1.1.Final
            Reporter: Eric van der Maarel


When you invoke and re-invoke org.jboss.invocation.InterceptorContext.proceed() from an interceptor in a chain of interceptors and the interceptor to be (re-)invoked is a org.jboss.invocation.ChainedInterceptor or WeavedInterceptor, a CannotProceedException is thrown.

This bug has been described and analysed in the context of the ejb3 container, on the forum at https://community.jboss.org/message/853547.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 06:34:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Jan 2014 06:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1781) Message: write/read the
 payload last when marshalling
In-Reply-To: <JIRA.12529852.1390219278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529852.1390219278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529852.1390219278000.8909.1390476868628@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938205#comment-12938205 ] 

Bela Ban commented on JGRP-1781:
--------------------------------

For now, I'll write the length field even for single messages, to have the same code for parsing of single messages and message batches. With NIO.2 in 4.0, this will change anyway
                
> Message: write/read the payload last when marshalling
> -----------------------------------------------------
>
>                 Key: JGRP-1781
>                 URL: https://issues.jboss.org/browse/JGRP-1781
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When (un)marshalling a message, we process the fields in this order:
> # Sender and receiver addresses
> # Flags
> # Payload
> # Headers
> I'd like to change this to move processing of the payload to the end because
> * If payload refers to a different buffer (JGRP-1773), then we don't need to read the bytes, but currently have to skip N bytes to read the headers. If the payload was at the end, this wouldn't be needed
> * Once we use NIO.2 and gathering writes, we'd pass a couple of buffers to the socket write and therefore it's simpler if the payload is written last. Ditto for scattering reads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 06:56:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Jan 2014 06:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2788) Upgrade PicketLink to
	2.5.2.Final
In-Reply-To: <JIRA.12530088.1390393405000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530088.1390393405000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530088.1390393405000.8945.1390478188776@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2788:
-----------------------------------

    Assignee: Pedro Igor  (was: Darran Lofthouse)

    
> Upgrade PicketLink to 2.5.2.Final
> ---------------------------------
>
>                 Key: WFLY-2788
>                 URL: https://issues.jboss.org/browse/WFLY-2788
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>             Fix For: 8.0.0.Final
>
>
> Upgrade to the latest released PicketLink 2.5.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 issues at jboss.org  Thu Jan 23 07:30:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 07:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.8988.1390480228995@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938221#comment-12938221 ] 

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Radim Hatlapatka <rhatlapa at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from ON_QA to VERIFIED
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this 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 issues at jboss.org  Thu Jan 23 07:30:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 07:30:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.8992.1390480229194@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938222#comment-12938222 ] 

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Radim Hatlapatka <rhatlapa at redhat.com> changed the Status of [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634] from ON_QA to VERIFIED
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 07:44:29 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 23 Jan 2014 07:44:29 -0500 (EST)
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.9033.1390481069001@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 reopened WFLY-1701:
-----------------------------------



https://github.com/wolfc/jboss-eap/commit/5c068571e97fb31f23ffc80d4a0ad221f48545d1 needs to be up-ported
                
> 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
>      Security Level: Public(Everyone can see) 
>          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.Final
>
>
> 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 issues at jboss.org  Thu Jan 23 07:46:29 2014
From: issues at jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 23 Jan 2014 07:46:29 -0500 (EST)
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.9043.1390481189569@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:
----------------------------------

    Priority: Blocker  (was: Major)

    
> 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
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.1, MS Windows server 
>            Reporter: Tom Ross
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Thu Jan 23 08:12:28 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Thu, 23 Jan 2014 08:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2735) read-operation-names casues
 NullPointerException
In-Reply-To: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529095.1389360809000.9088.1390482748942@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938234#comment-12938234 ] 

Stan Silvert commented on WFLY-2735:
------------------------------------

I think this could be related to Kabir's fix in WFLY-2131.

 CLI GUI makes this call at startup.  It doesn't cause any serious problems in CLI GUI, but the NPE on the server looks ugly.
                
> read-operation-names casues NullPointerException
> ------------------------------------------------
>
>                 Key: WFLY-2735
>                 URL: https://issues.jboss.org/browse/WFLY-2735
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
>         at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>         at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         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.1.Final.jar:2.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 issues at jboss.org  Thu Jan 23 08:18:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 23 Jan 2014 08:18:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2801) component upgrade to
 Hibernate ORM 4.3.1.Final
In-Reply-To: <JIRA.12530199.1390482993049@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530199.1390482993049@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530199.1390482993049.9104.1390483108561@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2801:
----------------------------------

             Summary: component upgrade to Hibernate ORM 4.3.1.Final
                 Key: WFLY-2801
                 URL: https://issues.jboss.org/browse/WFLY-2801
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.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 issues at jboss.org  Thu Jan 23 08:20:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 23 Jan 2014 08:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2801) component upgrade to
 Hibernate ORM 4.3.1.Final
In-Reply-To: <JIRA.12530199.1390482993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530199.1390482993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530199.1390482993000.9106.1390483228616@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938236#comment-12938236 ] 

Scott Marlow commented on WFLY-2801:
------------------------------------

EE (JPA) container managed tck tests pass with this change.
                
> component upgrade to Hibernate ORM 4.3.1.Final
> ----------------------------------------------
>
>                 Key: WFLY-2801
>                 URL: https://issues.jboss.org/browse/WFLY-2801
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.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 issues at jboss.org  Thu Jan 23 08:46:29 2014
From: issues at jboss.org (Esteban Aliverti (JIRA))
Date: Thu, 23 Jan 2014 08:46:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-414) Queries do not work with
 chained accessors as arguments
In-Reply-To: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530172.1390446870000.9145.1390484789054@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Esteban Aliverti reassigned DROOLS-414:
---------------------------------------

    Assignee: Esteban Aliverti  (was: Mark Proctor)

    
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
>                 Key: DROOLS-414
>                 URL: https://issues.jboss.org/browse/DROOLS-414
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Esteban Aliverti
>
> When processing a query CE that uses chained property accessors:
> when
>   $x : Foo()
>   myQuery( $x.bar ; ) 
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will 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 issues at jboss.org  Thu Jan 23 08:48:28 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 23 Jan 2014 08:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-414) Queries do not work with
 chained accessors as arguments
In-Reply-To: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530172.1390446870000.9150.1390484908675@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-414:
----------------------------------

    Assignee: Mario Fusco  (was: Esteban Aliverti)

    
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
>                 Key: DROOLS-414
>                 URL: https://issues.jboss.org/browse/DROOLS-414
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> When processing a query CE that uses chained property accessors:
> when
>   $x : Foo()
>   myQuery( $x.bar ; ) 
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will 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 issues at jboss.org  Thu Jan 23 08:48:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 23 Jan 2014 08:48:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-414) Queries do not work with
 chained accessors as arguments
In-Reply-To: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530172.1390446870000.9157.1390484909016@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-414:
-------------------------------

    Issue Type: Feature Request  (was: Bug)

    
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
>                 Key: DROOLS-414
>                 URL: https://issues.jboss.org/browse/DROOLS-414
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> When processing a query CE that uses chained property accessors:
> when
>   $x : Foo()
>   myQuery( $x.bar ; ) 
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will 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 issues at jboss.org  Thu Jan 23 08:52:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 08:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.9170.1390485148768@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBMETA-371:
---------------------------------------

    Assignee: Brian Stansberry

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Thu Jan 23 08:52:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 23 Jan 2014 08:52:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.9177.1390485149190@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2797:
---------------------------------

    Assignee: Scott Marlow  (was: David Lloyd)

    
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: Scott Marlow
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Thu Jan 23 08:52:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 23 Jan 2014 08:52:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.9182.1390485149536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2797:
------------------------------

    Fix Version/s: 8.0.0.Final

    
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Thu Jan 23 08:54:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 23 Jan 2014 08:54:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.9186.1390485268851@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2797:
------------------------------

    Component/s: JPA / Hibernate
                     (was: EJB)

    
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Thu Jan 23 08:56:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 23 Jan 2014 08:56:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-414) Queries do not work with
 chained accessors as arguments
In-Reply-To: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530172.1390446870000.9192.1390485389157@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938249#comment-12938249 ] 

Mario Fusco commented on DROOLS-414:
------------------------------------

For what regards queries documentation clearly states that

The following is not yet supported:
    List and Map unification
    Variables for the fields of facts
    Expression unification - pred( X, X + 1, X * Y / 7 )

For this reason I changed this ticket from bug to feature request. Moreover I developed a test case reproducing this issue.

{source}
    @Test
    public void testQueryWithAccessorAsArgument() throws Exception {
        String str =
                "import org.drools.compiler.Person\n" +
                "global java.util.List persons;\n" +
                "\n" +
                "query contains(String $s, String $c)\n" +
                "    $s := String( this.contains( $c ) )\n" +
                "end\n" +
                "\n" +
                "rule R when\n" +
                "    $p : Person()\n" +
                "    contains( $p.name, \"a\"; )\n" +
                "then\n" +
                "    persons.add( $p );\n" +
                "end\n";

        KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        List<Person> personsWithA = new ArrayList<Person>();
        ksession.setGlobal("persons", personsWithA);

        ksession.insert("Mark");
        ksession.insert("Edson");
        ksession.insert("Mario");
        ksession.insert(new Person("Mark"));
        ksession.insert(new Person("Edson"));
        ksession.insert(new Person("Mario"));
        ksession.fireAllRules();

        assertEquals(2, personsWithA.size());
    }
{source}
                
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
>                 Key: DROOLS-414
>                 URL: https://issues.jboss.org/browse/DROOLS-414
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> When processing a query CE that uses chained property accessors:
> when
>   $x : Foo()
>   myQuery( $x.bar ; ) 
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will 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 issues at jboss.org  Thu Jan 23 08:56:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 23 Jan 2014 08:56:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-414) Queries do not work with
 chained accessors as arguments
In-Reply-To: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530172.1390446870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530172.1390446870000.9194.1390485389288@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938249#comment-12938249 ] 

Mario Fusco edited comment on DROOLS-414 at 1/23/14 8:56 AM:
-------------------------------------------------------------

For what regards queries documentation clearly states that

The following is not yet supported:
    List and Map unification
    Variables for the fields of facts
    Expression unification - pred( X, X + 1, X * Y / 7 )

For this reason I changed this ticket from bug to feature request. Moreover I developed a test case reproducing this issue.

{code}
    @Test
    public void testQueryWithAccessorAsArgument() throws Exception {
        String str =
                "import org.drools.compiler.Person\n" +
                "global java.util.List persons;\n" +
                "\n" +
                "query contains(String $s, String $c)\n" +
                "    $s := String( this.contains( $c ) )\n" +
                "end\n" +
                "\n" +
                "rule R when\n" +
                "    $p : Person()\n" +
                "    contains( $p.name, \"a\"; )\n" +
                "then\n" +
                "    persons.add( $p );\n" +
                "end\n";

        KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        List<Person> personsWithA = new ArrayList<Person>();
        ksession.setGlobal("persons", personsWithA);

        ksession.insert("Mark");
        ksession.insert("Edson");
        ksession.insert("Mario");
        ksession.insert(new Person("Mark"));
        ksession.insert(new Person("Edson"));
        ksession.insert(new Person("Mario"));
        ksession.fireAllRules();

        assertEquals(2, personsWithA.size());
    }
{code}
                
      was (Author: mfusco):
    For what regards queries documentation clearly states that

The following is not yet supported:
    List and Map unification
    Variables for the fields of facts
    Expression unification - pred( X, X + 1, X * Y / 7 )

For this reason I changed this ticket from bug to feature request. Moreover I developed a test case reproducing this issue.

{source}
    @Test
    public void testQueryWithAccessorAsArgument() throws Exception {
        String str =
                "import org.drools.compiler.Person\n" +
                "global java.util.List persons;\n" +
                "\n" +
                "query contains(String $s, String $c)\n" +
                "    $s := String( this.contains( $c ) )\n" +
                "end\n" +
                "\n" +
                "rule R when\n" +
                "    $p : Person()\n" +
                "    contains( $p.name, \"a\"; )\n" +
                "then\n" +
                "    persons.add( $p );\n" +
                "end\n";

        KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        List<Person> personsWithA = new ArrayList<Person>();
        ksession.setGlobal("persons", personsWithA);

        ksession.insert("Mark");
        ksession.insert("Edson");
        ksession.insert("Mario");
        ksession.insert(new Person("Mark"));
        ksession.insert(new Person("Edson"));
        ksession.insert(new Person("Mario"));
        ksession.fireAllRules();

        assertEquals(2, personsWithA.size());
    }
{source}
                  
> Queries do not work with chained accessors as arguments
> -------------------------------------------------------
>
>                 Key: DROOLS-414
>                 URL: https://issues.jboss.org/browse/DROOLS-414
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> When processing a query CE that uses chained property accessors:
> when
>   $x : Foo()
>   myQuery( $x.bar ; ) 
> then
> the QueryElementBuilder considers the whole expression $x.bar as a variable. Since no variable with that name has been bound, it is taken to be a new declaration, and thus an output. This results in an inconsistent behavior, since an obvious constraint will 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 issues at jboss.org  Thu Jan 23 08:58:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 08:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS /
 Hibernate JPA integration
In-Reply-To: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526628.1385994740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526628.1385994740000.9198.1390485508663@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938250#comment-12938250 ] 

RH Bugzilla Integration commented on WFLY-2593:
-----------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1037636|https://bugzilla.redhat.com/show_bug.cgi?id=1037636] from ON_QA to VERIFIED
                
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
>                 Key: WFLY-2593
>                 URL: https://issues.jboss.org/browse/WFLY-2593
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: No Release
>         Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
>            Reporter: Michael Kozak
>            Assignee: Scott Marlow
>            Priority: Critical
>             Fix For: No Release
>
>         Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA. 
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 09:00:29 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 23 Jan 2014 09:00:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2802) Component upgrade to
 Hibernate Search 4.5.0.CR1
In-Reply-To: <JIRA.12530203.1390485628348@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530203.1390485628348@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530203.1390485628348.9201.1390485629686@jira02.app.mwc.hst.phx2.redhat.com>

Sanne Grinovero created WFLY-2802:
-------------------------------------

             Summary: Component upgrade to Hibernate Search 4.5.0.CR1
                 Key: WFLY-2802
                 URL: https://issues.jboss.org/browse/WFLY-2802
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, JPA / Hibernate
            Reporter: Sanne Grinovero
            Assignee: Sanne Grinovero
             Fix For: 8.0.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 issues at jboss.org  Thu Jan 23 09:02:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 09:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.9204.1390485748647@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938251#comment-12938251 ] 

Brian Stansberry commented on JBMETA-371:
-----------------------------------------

No, its design is wrong given the requirements. The requirement was to support vault expressions, and this can't. We wouldn't have bothered with the PropertyResolver notion if we weren't aiming to get vault expression support.

This could be replaced by an ExpressionReplacer + ExpressionResolver which separates the concerns better. The ExpressionReplacer simply looks for ${} and passes the contents therein to ExpressionResolver. The ExpressionResolver deals with the format of the expression.

I'll file a separate issue for that as it's too big a change to do, particularly for any backport. Plus I have no time. ;) Doing it with the current stuff would require changing the contract of PropertyResolver.

I think I have a fairly simple but hacky fix for what we have now. Knock on wood.
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Thu Jan 23 09:08:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 23 Jan 2014 09:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.9217.1390486108741@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938252#comment-12938252 ] 

Scott Marlow commented on WFLY-2797:
------------------------------------

Thanks Tomaz, I didn't see this jira... :)
                
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Thu Jan 23 09:10:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 23 Jan 2014 09:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.9225.1390486228637@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2797.
--------------------------------

    Fix Version/s:     (was: 8.0.0.Final)
       Resolution: Duplicate Issue


This is a duplicate of WFLY-2801.
                
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: Scott Marlow
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Thu Jan 23 09:32:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 09:32:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.9284.1390487549147@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938266#comment-12938266 ] 

Brian Stansberry commented on JBMETA-371:
-----------------------------------------

https://github.com/jboss/metadata/pull/57
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Thu Jan 23 09:34:28 2014
From: issues at jboss.org (Gytis Trikleris (JIRA))
Date: Thu, 23 Jan 2014 09:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2803) Update Narayana to 5.0.0.Final
In-Reply-To: <JIRA.12530208.1390487663644@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530208.1390487663644@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530208.1390487663644.9291.1390487668796@jira02.app.mwc.hst.phx2.redhat.com>

Gytis Trikleris created WFLY-2803:
-------------------------------------

             Summary: Update Narayana to 5.0.0.Final
                 Key: WFLY-2803
                 URL: https://issues.jboss.org/browse/WFLY-2803
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Transactions
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
             Fix For: 8.0.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 issues at jboss.org  Thu Jan 23 09:46:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 09:46:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2514) Using directory grouping
 by-type results in the wrong logging.properties file being used
In-Reply-To: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525194.1384479524000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525194.1384479524000.9336.1390488390883@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938281#comment-12938281 ] 

RH Bugzilla Integration commented on WFLY-2514:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1050068|https://bugzilla.redhat.com/show_bug.cgi?id=1050068] from ON_QA to VERIFIED
                
> Using directory grouping by-type results in the wrong logging.properties file being used
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2514
>                 URL: https://issues.jboss.org/browse/WFLY-2514
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> When defining servers with {{directory-grouping="by-type"}} the wrong directory is used in the {{ManagedServerBootCmdFactory}}. This causes the {{domain/configuration/logging.properties}} to always be used which is the incorrect configuration to use.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 10:08:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 10:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2777) JNDI external context binding
 doesn't properly set a module class loader
In-Reply-To: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529837.1390213800000.9361.1390489709291@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2777:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1057168

    
> JNDI external context binding doesn't properly set a module class loader
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2777
>                 URL: https://issues.jboss.org/browse/WFLY-2777
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> The current implementation of JNDI external context binding takes a module class loader if based by a module for loading a initialContextClassName only (note that this initialContextClassName is one of InitialContext, InitialDirContext or InitialLdapContext). While it rather needs to switch TCCL to the module class loader to be available when trying to get a new instance of it at line 87, see the snippet below. As this is the moment when it constructs a new initial context from a factory class given by environment properties.
> {code:java|title=naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java}
> 83             Module module = Module.getBootModuleLoader().loadModule(ModuleIdentifier.fromString(initialContextModule));
> 84             loader = module.getClassLoader();
> 85             initialContextClass = Class.forName(initialContextClassName, true, module.getClassLoader());
> 86             Constructor ctor = initialContextClass.getConstructor(Hashtable.class);
> 87             context = (Context) ctor.newInstance(newEnvironment);
> {code}
> Due to this issue the binding fails with an exception as follows:
> {noformat}
> 17:02:46,740 ERROR [stderr] (default task-1) Caused by: java.lang.reflect.InvocationTargetException
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 17:02:46,741 ERROR [stderr] (default task-1)   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 17:02:46,741 ERROR [stderr] (default task-1)   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:46)
> 17:02:46,743 ERROR [stderr] (default task-1)   at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> 17:02:46,743 ERROR [stderr] (default task-1)   ... 36 more
> 17:02:46,744 ERROR [stderr] (default task-1) Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory from classloader ModuleClassLoader for Module &quot;deployment.messagesender.war:main&quot; from Service Module Loader
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.directory.InitialDirContext.&lt;init&gt;(InitialDirContext.java:101)
> 17:02:46,745 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.&lt;init&gt;(InitialContext.java:90)
> 17:02:46,746 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.init(InitialContext.java:242)
> 17:02:46,747 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,747 ERROR [stderr] (default task-1)   ... 43 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 issues at jboss.org  Thu Jan 23 10:08:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 10:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2660) LDAP Group Loading - Should
 Not Fail for Non-existent User.
In-Reply-To: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528037.1387216541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528037.1387216541000.9366.1390489709609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938290#comment-12938290 ] 

RH Bugzilla Integration commented on WFLY-2660:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1051240|https://bugzilla.redhat.com/show_bug.cgi?id=1051240] from ON_QA to VERIFIED
                
> LDAP Group Loading - Should Not Fail for Non-existent User.
> -----------------------------------------------------------
>
>                 Key: WFLY-2660
>                 URL: https://issues.jboss.org/browse/WFLY-2660
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Where a security realm is configured to load groups from LDAP it should not cause an authentication failure if the user is not found in LDAP.
> One example is local authentication where the user may not exist.
> Another is domain mode servers where the servers have a custom name and generated password that they use to connect back to the local host controller.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 10:08:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 10:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2777) JNDI external context binding
 doesn't properly set a module class loader
In-Reply-To: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529837.1390213800000.9370.1390489709831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938291#comment-12938291 ] 

RH Bugzilla Integration commented on WFLY-2777:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1057168|https://bugzilla.redhat.com/show_bug.cgi?id=1057168] from NEW to ASSIGNED
                
> JNDI external context binding doesn't properly set a module class loader
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2777
>                 URL: https://issues.jboss.org/browse/WFLY-2777
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> The current implementation of JNDI external context binding takes a module class loader if based by a module for loading a initialContextClassName only (note that this initialContextClassName is one of InitialContext, InitialDirContext or InitialLdapContext). While it rather needs to switch TCCL to the module class loader to be available when trying to get a new instance of it at line 87, see the snippet below. As this is the moment when it constructs a new initial context from a factory class given by environment properties.
> {code:java|title=naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java}
> 83             Module module = Module.getBootModuleLoader().loadModule(ModuleIdentifier.fromString(initialContextModule));
> 84             loader = module.getClassLoader();
> 85             initialContextClass = Class.forName(initialContextClassName, true, module.getClassLoader());
> 86             Constructor ctor = initialContextClass.getConstructor(Hashtable.class);
> 87             context = (Context) ctor.newInstance(newEnvironment);
> {code}
> Due to this issue the binding fails with an exception as follows:
> {noformat}
> 17:02:46,740 ERROR [stderr] (default task-1) Caused by: java.lang.reflect.InvocationTargetException
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 17:02:46,741 ERROR [stderr] (default task-1)   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 17:02:46,741 ERROR [stderr] (default task-1)   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:46)
> 17:02:46,743 ERROR [stderr] (default task-1)   at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> 17:02:46,743 ERROR [stderr] (default task-1)   ... 36 more
> 17:02:46,744 ERROR [stderr] (default task-1) Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory from classloader ModuleClassLoader for Module &quot;deployment.messagesender.war:main&quot; from Service Module Loader
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.directory.InitialDirContext.&lt;init&gt;(InitialDirContext.java:101)
> 17:02:46,745 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.&lt;init&gt;(InitialContext.java:90)
> 17:02:46,746 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.init(InitialContext.java:242)
> 17:02:46,747 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,747 ERROR [stderr] (default task-1)   ... 43 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 issues at jboss.org  Thu Jan 23 10:34:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Jan 2014 10:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1781) Message: write/read the
 payload last when marshalling
In-Reply-To: <JIRA.12529852.1390219278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529852.1390219278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529852.1390219278000.9431.1390491268946@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1781.
----------------------------

    Resolution: Done

    
> Message: write/read the payload last when marshalling
> -----------------------------------------------------
>
>                 Key: JGRP-1781
>                 URL: https://issues.jboss.org/browse/JGRP-1781
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When (un)marshalling a message, we process the fields in this order:
> # Sender and receiver addresses
> # Flags
> # Payload
> # Headers
> I'd like to change this to move processing of the payload to the end because
> * If payload refers to a different buffer (JGRP-1773), then we don't need to read the bytes, but currently have to skip N bytes to read the headers. If the payload was at the end, this wouldn't be needed
> * Once we use NIO.2 and gathering writes, we'd pass a couple of buffers to the socket write and therefore it's simpler if the payload is written last. Ditto for scattering reads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 10:34:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Jan 2014 10:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1773)
 TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
In-Reply-To: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529686.1389959943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529686.1389959943000.9435.1390491269096@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1773.
----------------------------

    Resolution: Done

    
> TP$MyHandler.handleSingleMessage() makes an unnecessary copy of the buffer
> --------------------------------------------------------------------------
>
>                 Key: JGRP-1773
>                 URL: https://issues.jboss.org/browse/JGRP-1773
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When a single message is received, we pass it to the thread pool for parsing, passing a copy of the byte array to the MyHandler runnable.
> The parsing then creates a new Message and calls readFrom(). This method reads the headers and then creates a payload buffer of the size read from the input stream, then copies {{size}} bytes from the input stream to the mesage's payload.
> This is an unneeded copy; as we already have a copy of the byte array, we only need to *reference* the byte array from the message and set the offset and length, saving us one copy of the buffer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 10:48:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 10:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.9478.1390492108888@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938305#comment-12938305 ] 

RH Bugzilla Integration commented on WFLY-1594:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> changed the Status of [bug 1051189|https://bugzilla.redhat.com/show_bug.cgi?id=1051189] from ON_QA to VERIFIED
                
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 11:08:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Jan 2014 11:08:28 -0500 (EST)
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.9519.1390493308958@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: Future
                       (was: 3.5)

    
> 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: Future
>
>         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 issues at jboss.org  Thu Jan 23 11:10:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 11:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2777) JNDI external context binding
 doesn't properly set a module class loader
In-Reply-To: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529837.1390213800000.9522.1390493428593@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938312#comment-12938312 ] 

RH Bugzilla Integration commented on WFLY-2777:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1057168|https://bugzilla.redhat.com/show_bug.cgi?id=1057168] from ASSIGNED to POST
                
> JNDI external context binding doesn't properly set a module class loader
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2777
>                 URL: https://issues.jboss.org/browse/WFLY-2777
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> The current implementation of JNDI external context binding takes a module class loader if based by a module for loading a initialContextClassName only (note that this initialContextClassName is one of InitialContext, InitialDirContext or InitialLdapContext). While it rather needs to switch TCCL to the module class loader to be available when trying to get a new instance of it at line 87, see the snippet below. As this is the moment when it constructs a new initial context from a factory class given by environment properties.
> {code:java|title=naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java}
> 83             Module module = Module.getBootModuleLoader().loadModule(ModuleIdentifier.fromString(initialContextModule));
> 84             loader = module.getClassLoader();
> 85             initialContextClass = Class.forName(initialContextClassName, true, module.getClassLoader());
> 86             Constructor ctor = initialContextClass.getConstructor(Hashtable.class);
> 87             context = (Context) ctor.newInstance(newEnvironment);
> {code}
> Due to this issue the binding fails with an exception as follows:
> {noformat}
> 17:02:46,740 ERROR [stderr] (default task-1) Caused by: java.lang.reflect.InvocationTargetException
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 17:02:46,741 ERROR [stderr] (default task-1)   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 17:02:46,741 ERROR [stderr] (default task-1)   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:46)
> 17:02:46,743 ERROR [stderr] (default task-1)   at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> 17:02:46,743 ERROR [stderr] (default task-1)   ... 36 more
> 17:02:46,744 ERROR [stderr] (default task-1) Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory from classloader ModuleClassLoader for Module &quot;deployment.messagesender.war:main&quot; from Service Module Loader
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.directory.InitialDirContext.&lt;init&gt;(InitialDirContext.java:101)
> 17:02:46,745 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.&lt;init&gt;(InitialContext.java:90)
> 17:02:46,746 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.init(InitialContext.java:242)
> 17:02:46,747 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,747 ERROR [stderr] (default task-1)   ... 43 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 issues at jboss.org  Thu Jan 23 11:10:28 2014
From: issues at jboss.org (Arun Gupta (JIRA))
Date: Thu, 23 Jan 2014 11:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2804) Add -u and -p shortcuts to
	jboss-cli
In-Reply-To: <JIRA.12530216.1390493394698@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530216.1390493394698@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530216.1390493394698.9525.1390493428763@jira02.app.mwc.hst.phx2.redhat.com>

Arun Gupta created WFLY-2804:
--------------------------------

             Summary: Add -u and -p shortcuts to jboss-cli
                 Key: WFLY-2804
                 URL: https://issues.jboss.org/browse/WFLY-2804
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Arun Gupta
            Priority: Minor


jboss-cli only provides --user and --password as the options. It would be convenient to add -u and -p as shortcut options as this will bring consistency with add-user 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 issues at jboss.org  Thu Jan 23 11:14:28 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 23 Jan 2014 11:14:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2805) Fix the classpath resolution
 in jconsole.sh (and .bat)
In-Reply-To: <JIRA.12530217.1390493571797@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530217.1390493571797@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530217.1390493571797.9530.1390493668549@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-2805:
-----------------------------------------

             Summary: Fix the classpath resolution in jconsole.sh (and .bat)
                 Key: WFLY-2805
                 URL: https://issues.jboss.org/browse/WFLY-2805
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Scripts
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.Final


The jconsole scripts use a some hardcoded module names and the module path to resolve the classpath. This however might not work with a patched instance, since modules get invalidated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 11:16:29 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 23 Jan 2014 11:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-320) Allow jconsole to be launched
 as a modular application
In-Reply-To: <JIRA.12484676.1360603035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484676.1360603035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484676.1360603035000.9534.1390493789824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938316#comment-12938316 ] 

Emanuel Muckenhuber commented on WFLY-320:
------------------------------------------

I am going to update the scripts to use the jboss-cli-client.jar artifact instead of dynamically trying to resolve the classpath using the list of modules and the module path for now. 
                
> Allow jconsole to be launched as a modular application
> ------------------------------------------------------
>
>                 Key: WFLY-320
>                 URL: https://issues.jboss.org/browse/WFLY-320
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Scripts
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> Make the jconsole scripts launch jconsole as as a modular application. Get rid of the classpath building that resulted in AS7-6498.
> Some (mildly edited) discussion:
> bstansberry: BTW, I filed a JIRA to make the vault tool a proper modular app in AS next. I'm not sure if that's doable for jconsole
> [10:37am] darranl: bstansberry: Yes vault should be modular - I don't believe jconsole is as easily possible unless we add a module for the jconsole classes
> [10:38am] darranl: bstansberry: the problem with jconsole was that we actually needed to call jconsole which I think was a binary so we were just created an extended classpath for that binary to use
> [10:38am] bstansberry: darranl: ok, will do. I didn't file a JIRA for modular jconsole because I figured there would be problems
> [10:39am] darranl: bstansberry: having said that it may be possible now to just switch to use the client jar - that did not exist at the time the jconsole script was first written
> [10:40am] darranl: but at this point may be safer to just update the root of the modules folder and switch to client later
> [10:40am] bstansberry: darranl: this will become more of an issue once we have patching
> [10:40am] bstansberry: since this script won't pick up any patches we may have issued for the listed modules
> [10:40am] bstansberry: and no way are we going to add that to the script
> [10:43am] dmlloyd: I've booted jconsole from within modules before
> [10:43am] dmlloyd: it's possible
> [10:43am] darranl: If it is possbile then maybe we can just make it modular
> [10:44am] dmlloyd: java -jar ~/.m2/repository/org/jboss/modules/jboss-modules/1.1.4.GA/jboss-modules-1.1.4.GA.jar -jar ~/local/jdk/home/lib/jconsole.jar
> [10:44am] dmlloyd: easy as bananas
> [10:45am] dmlloyd: if you use -cp you can also add dependencies via -dep
> [10:45am] dmlloyd: or we could create a jconsole module from openjdk even

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 11:16:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 11:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-320) Allow jconsole to be launched
 as a modular application
In-Reply-To: <JIRA.12484676.1360603035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484676.1360603035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484676.1360603035000.9537.1390493789992@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-320:
----------------------------------

    Fix Version/s: Awaiting Volunteers
                       (was: 8.0.0.CR1)
                       (was: 8.0.0.Final)

    
> Allow jconsole to be launched as a modular application
> ------------------------------------------------------
>
>                 Key: WFLY-320
>                 URL: https://issues.jboss.org/browse/WFLY-320
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Scripts
>            Reporter: Brian Stansberry
>             Fix For: Awaiting Volunteers
>
>
> Make the jconsole scripts launch jconsole as as a modular application. Get rid of the classpath building that resulted in AS7-6498.
> Some (mildly edited) discussion:
> bstansberry: BTW, I filed a JIRA to make the vault tool a proper modular app in AS next. I'm not sure if that's doable for jconsole
> [10:37am] darranl: bstansberry: Yes vault should be modular - I don't believe jconsole is as easily possible unless we add a module for the jconsole classes
> [10:38am] darranl: bstansberry: the problem with jconsole was that we actually needed to call jconsole which I think was a binary so we were just created an extended classpath for that binary to use
> [10:38am] bstansberry: darranl: ok, will do. I didn't file a JIRA for modular jconsole because I figured there would be problems
> [10:39am] darranl: bstansberry: having said that it may be possible now to just switch to use the client jar - that did not exist at the time the jconsole script was first written
> [10:40am] darranl: but at this point may be safer to just update the root of the modules folder and switch to client later
> [10:40am] bstansberry: darranl: this will become more of an issue once we have patching
> [10:40am] bstansberry: since this script won't pick up any patches we may have issued for the listed modules
> [10:40am] bstansberry: and no way are we going to add that to the script
> [10:43am] dmlloyd: I've booted jconsole from within modules before
> [10:43am] dmlloyd: it's possible
> [10:43am] darranl: If it is possbile then maybe we can just make it modular
> [10:44am] dmlloyd: java -jar ~/.m2/repository/org/jboss/modules/jboss-modules/1.1.4.GA/jboss-modules-1.1.4.GA.jar -jar ~/local/jdk/home/lib/jconsole.jar
> [10:44am] dmlloyd: easy as bananas
> [10:45am] dmlloyd: if you use -cp you can also add dependencies via -dep
> [10:45am] dmlloyd: or we could create a jconsole module from openjdk even

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 11:40:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 11:40:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2461) refactoring of character
 escaping in operation parameter values
In-Reply-To: <JIRA.12524468.1383828647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524468.1383828647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524468.1383828647000.9594.1390495229232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2461:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056933

    
> refactoring of character escaping in operation parameter values
> ---------------------------------------------------------------
>
>                 Key: WFLY-2461
>                 URL: https://issues.jboss.org/browse/WFLY-2461
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> There are potential issues with unescaping operation parameter values and command argument values that will be used as operation request parameter values.
> The culprit is that these values are parsed twice: first, with the general command line parser and the second time with the value type parser (which depends on the type of the value: could be list, property list, DMR, etc). Both parsers support and may perform unescaping. Which may lead to confusions and issues like WFLY-161 or WFLY-1791 and then confusing conditions in the code.
> The goal of this task is to not unescape parameter/argument values on the first parsing and leave it to the value type parsers. This concerns *only* parameter and argument value parsing, parsing of the other parts of operation requests and commands will remain as it 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 issues at jboss.org  Thu Jan 23 12:10:30 2014
From: issues at jboss.org (Bernd Eckenfels (JIRA))
Date: Thu, 23 Jan 2014 12:10:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-92) [tests]
 LoggerTests.testResourceBundle fails on german windows
In-Reply-To: <JIRA.12530228.1390496986468@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530228.1390496986468@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530228.1390496986468.9680.1390497030099@jira02.app.mwc.hst.phx2.redhat.com>

Bernd Eckenfels created LOGMGR-92:
-------------------------------------

             Summary: [tests] LoggerTests.testResourceBundle fails on german windows
                 Key: LOGMGR-92
                 URL: https://issues.jboss.org/browse/LOGMGR-92
             Project: JBoss Log Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.3.2.Final, 2.0.0.Beta1
         Environment: maven 3.0.2 on Win7x64 cygwin
            Reporter: Bernd Eckenfels
            Assignee: David Lloyd
            Priority: Minor


When I run "mvn test" for the logmanager build (various branches) on german Win7 it fails with 

Tests run: 42, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.834 sec <<< FAILURE!                                     
Results:                                                                                                        Failed tests:   testResourceBundle(org.jboss.logmanager.LoggerTests): Can't find org.jboss.logmanager.LoggerTests bundle    

Tests run:42 ,Failures:1, Errors:0,Skipped:0

ava.util.MissingResourceException: Can't find org.jboss.logmanager.LoggerTests bundle
	at java.util.logging.Logger.setupResourceInfo(Logger.java:1335)
	at java.util.logging.Logger.getLogger(Logger.java:335)
	at org.jboss.logmanager.Logger.getLogger(Logger.java:75)
	at org.jboss.logmanager.LoggerTests.testResourceBundle(LoggerTests.java:149)

It helps to copy src/test/resources/org/jboss/logmanager/LoggerTests_en.properties to LoggerTests.properties, however strangely enough it does not help to manually specify user.language=en in the surefire configuration. The test should at least skip itself if the locale is not specified correctly (or ship locale independend translation).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 12:12:28 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 23 Jan 2014 12:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-92) [tests]
 LoggerTests.testResourceBundle fails on german windows
In-Reply-To: <JIRA.12530228.1390496986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530228.1390496986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530228.1390496986000.9683.1390497148754@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned LOGMGR-92:
-----------------------------------

    Assignee: James Perkins  (was: David Lloyd)

    
> [tests] LoggerTests.testResourceBundle fails on german windows
> --------------------------------------------------------------
>
>                 Key: LOGMGR-92
>                 URL: https://issues.jboss.org/browse/LOGMGR-92
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.2.Final, 2.0.0.Beta1
>         Environment: maven 3.0.2 on Win7x64 cygwin
>            Reporter: Bernd Eckenfels
>            Assignee: James Perkins
>            Priority: Minor
>              Labels: i18n
>
> When I run "mvn test" for the logmanager build (various branches) on german Win7 it fails with 
> Tests run: 42, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.834 sec <<< FAILURE!                                     
> Results:                                                                                                        Failed tests:   testResourceBundle(org.jboss.logmanager.LoggerTests): Can't find org.jboss.logmanager.LoggerTests bundle    
> Tests run:42 ,Failures:1, Errors:0,Skipped:0
> ava.util.MissingResourceException: Can't find org.jboss.logmanager.LoggerTests bundle
> 	at java.util.logging.Logger.setupResourceInfo(Logger.java:1335)
> 	at java.util.logging.Logger.getLogger(Logger.java:335)
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:75)
> 	at org.jboss.logmanager.LoggerTests.testResourceBundle(LoggerTests.java:149)
> It helps to copy src/test/resources/org/jboss/logmanager/LoggerTests_en.properties to LoggerTests.properties, however strangely enough it does not help to manually specify user.language=en in the surefire configuration. The test should at least skip itself if the locale is not specified correctly (or ship locale independend translation).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 12:18:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 12:18:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-372) Rework the
 PropertyReplacer/PropertyResolver contract
In-Reply-To: <JIRA.12530230.1390497416532@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530230.1390497416532@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530230.1390497416532.9703.1390497508568@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created JBMETA-372:
---------------------------------------

             Summary: Rework the PropertyReplacer/PropertyResolver contract
                 Key: JBMETA-372
                 URL: https://issues.jboss.org/browse/JBMETA-372
             Project: JBoss Metadata
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: common
            Reporter: Brian Stansberry


See JBMETA-371 for issues with the current contract. I believe we need a better separation between recognizing the existence of an expression and resolving it. The JBMETA-371 fix is just a 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 issues at jboss.org  Thu Jan 23 12:26:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Jan 2014 12:26:28 -0500 (EST)
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.9739.1390497988742@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 resolved WFLY-1666.
------------------------------------

    Resolution: Cannot Reproduce Bug


Subsequent re-factoring appears to have addressed this.
                
> 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: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Thu Jan 23 12:30:28 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Thu, 23 Jan 2014 12:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments
 that use CXFServlet but have not disabled the WS subsystem
In-Reply-To: <JIRA.12530232.1390498114454@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530232.1390498114454@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530232.1390498114454.9748.1390498228764@jira02.app.mwc.hst.phx2.redhat.com>

Kyle Lape created WFLY-2806:
-------------------------------

             Summary: Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem
                 Key: WFLY-2806
                 URL: https://issues.jboss.org/browse/WFLY-2806
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Kyle Lape
            Assignee: Alessio Soldano


If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be 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 issues at jboss.org  Thu Jan 23 12:30:28 2014
From: issues at jboss.org (Kyle Lape (JIRA))
Date: Thu, 23 Jan 2014 12:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments
 that use CXFServlet but have not disabled the WS subsystem
In-Reply-To: <JIRA.12530232.1390498114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530232.1390498114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530232.1390498114000.9752.1390498228926@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kyle Lape updated WFLY-2806:
----------------------------

    Description: If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled.  (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.)  (was: If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled.)

    
> Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2806
>                 URL: https://issues.jboss.org/browse/WFLY-2806
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Kyle Lape
>            Assignee: Alessio Soldano
>
> If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled.  (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 12:54:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 12:54:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-561) Disable runtime statistics by
 default; improve usability of enabling/disabling them
In-Reply-To: <JIRA.12489316.1365803046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489316.1365803046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489316.1365803046000.9825.1390499668480@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938353#comment-12938353 ] 

Brian Stansberry commented on WFLY-561:
---------------------------------------

Note to self: EJB3 has enable-statistics as well.
                
> Disable runtime statistics by default; improve usability of enabling/disabling them
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-561
>                 URL: https://issues.jboss.org/browse/WFLY-561
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 9.0.0.CR1
>
>
> Ensure that all core resources and standard subsystem resources that gather runtime statistics have statistics gathering disabled by default. The default configuration should be optimized for performance.
> Ensure that the mechanism to enable/disable statistics gathering is consistent across resources (i.e. a boolean attribute with a consistent name and location in the relevant portion of the resource tree).
> Implement other relevant points agreed upon in the November 2012 AS design meetings in Brno.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 13:16:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 13:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-373) Kie Maven plugin don't use
 the project classpath
In-Reply-To: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527372.1386611608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527372.1386611608000.9854.1390500989866@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938360#comment-12938360 ] 

RH Bugzilla Integration commented on DROOLS-373:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1039676|https://bugzilla.redhat.com/show_bug.cgi?id=1039676] from ON_QA to VERIFIED
                
> Kie Maven plugin don't use the project classpath
> ------------------------------------------------
>
>                 Key: DROOLS-373
>                 URL: https://issues.jboss.org/browse/DROOLS-373
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.1.Final
>
>         Attachments: drools6scratch-kiemavenclasspath.zip
>
>
> When compiling drls the kie maven plugin uses the plugin classpath instead of the project one. This imply that it is necessary to duplicate the dependencies used by the kie project also inside the plugin declaration, as reported by this email: http://drools.46999.n3.nabble.com/rules-users-Drool-6-0-0-Final-2-question-re-kie-maven-plugin-please-td4027117.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 issues at jboss.org  Thu Jan 23 15:12:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 15:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.9966.1390507948882@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938385#comment-12938385 ] 

Brian Stansberry commented on WFLY-880:
---------------------------------------

[~ramazanyich] No, outcome => success simply means the operation executed successfully (i.e. in this case it read the requested data), kind of like an HTTP 200 response code. It doesn't mean anything about the particular return value. See https://docs.jboss.org/author/display/WFLY8/Admin+Guide#AdminGuide-FormatofaDetypedOperationResponse for details.
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 15:20:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 15:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-705) Implement a User Agent and
 Remote Address Filter for the HTTP Management Interface
In-Reply-To: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450792.1319827535000.9975.1390508428942@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938386#comment-12938386 ] 

Brian Stansberry commented on WFLY-705:
---------------------------------------

[~adietish] Sounds fine. My last comment didn't mean that (it was just about details of the JIRA pull request workflow) but if there's a separate JIRA for config stuff, that's fine.
                
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-705
>                 URL: https://issues.jboss.org/browse/WFLY-705
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Andre Dietisheim
>             Fix For: 8.0.0.CR1
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 15:24:29 2014
From: issues at jboss.org (Eric van der Maarel (JIRA))
Date: Thu, 23 Jan 2014 15:24:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2800) Re-invoking
 InterceptorContext.proceed() throws CannoteProceedException
In-Reply-To: <JIRA.12530192.1390476344000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530192.1390476344000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530192.1390476344000.9983.1390508669050@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric van der Maarel updated WFLY-2800:
--------------------------------------

    Affects Version/s:     (was: JBoss AS7 7.1.1.Final)
      Forum Reference: https://community.jboss.org/message/853547

    
> Re-invoking InterceptorContext.proceed() throws CannoteProceedException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2800
>                 URL: https://issues.jboss.org/browse/WFLY-2800
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Eric van der Maarel
>
> When you invoke and re-invoke org.jboss.invocation.InterceptorContext.proceed() from an interceptor in a chain of interceptors and the interceptor to be (re-)invoked is a org.jboss.invocation.ChainedInterceptor or WeavedInterceptor, a CannotProceedException is thrown.
> This bug has been described and analysed in the context of the ejb3 container, on the forum at https://community.jboss.org/message/853547.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 16:24:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Jan 2014 16:24:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2807) Messaging subsystem
 runtime-queue resource is not registered as "runtime-only"
In-Reply-To: <JIRA.12530242.1390512259117@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530242.1390512259117@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530242.1390512259117.10038.1390512268742@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2807:
--------------------------------------

             Summary: Messaging subsystem runtime-queue resource is not registered as "runtime-only"
                 Key: WFLY-2807
                 URL: https://issues.jboss.org/browse/WFLY-2807
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, JMS
    Affects Versions: 8.0.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Final


The runtime-queue resource only exists at runtime but isn't registered as such. I noticed this as ManagementClient does a recursive read-resource of the entire tree, but with include-runtime=false, but a CI run showed a failure reading one of these resources anyway:

```
21:01:01,754 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("read-attribute") failed - address: ([
    ("subsystem" => "messaging"),
    ("hornetq-server" => "default"),
    ("runtime-queue" => "jms.tempqueue.661a6b15-7863-4d6c-b4b1-f8d62d294ea5")
]) - failure description: "JBAS011676: No resource exists at address [
    (\"subsystem\" => \"messaging\"),
    (\"hornetq-server\" => \"default\"),
    (\"runtime-queue\" => \"jms.tempqueue.661a6b15-7863-4d6c-b4b1-f8d62d294ea5\")
]"
```

Doing read-resource with these is a bit problematic in any case, since a bunch of read-attribute calls get executed as steps (that's what the above was) but the resource can disappear in the middle. But that's a separate problem. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 16:34:28 2014
From: issues at jboss.org (Dennis Lee (JIRA))
Date: Thu, 23 Jan 2014 16:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-415) Guvnor guided editor can't
 save composite key's condition
In-Reply-To: <JIRA.12530243.1390512824886@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530243.1390512824886@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530243.1390512824886.10053.1390512868652@jira02.app.mwc.hst.phx2.redhat.com>

Dennis Lee created DROOLS-415:
---------------------------------

             Summary: Guvnor guided editor can't save composite key's condition
                 Key: DROOLS-415
                 URL: https://issues.jboss.org/browse/DROOLS-415
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Dennis Lee
            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 issues at jboss.org  Thu Jan 23 16:48:28 2014
From: issues at jboss.org (Dennis Lee (JIRA))
Date: Thu, 23 Jan 2014 16:48:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-415) Guvnor guided editor can't
 save when composite key's condition
In-Reply-To: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530243.1390512824000.10078.1390513708536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lee updated DROOLS-415:
------------------------------

              Summary: Guvnor guided editor can't save when composite key's condition  (was: Guvnor guided editor can't save composite key's condition)
        Fix Version/s: 5.5.0.Final
    Affects Version/s: 5.5.0.Final
          Environment: Windows
          Description: 
When i use to create rules on Guided editor, it can't save.

For example, my entity is a order entity. It have some keys.

Entity class : Order(id, ...so on..)
Entity class : OrderId(baseDate, orderId)
Keys : baseDate, orderId

It generated from hibernate generation's classes.

I created a rule on Guided editor

When
        order : Order(id.baseDate >= '...' && id.baseDate <= '..')
Then
         ....................

If i created this rule on Guvnor's guided editor, it could not save.





    
> Guvnor guided editor can't save when composite key's condition
> --------------------------------------------------------------
>
>                 Key: DROOLS-415
>                 URL: https://issues.jboss.org/browse/DROOLS-415
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows
>            Reporter: Dennis Lee
>            Assignee: Mark Proctor
>             Fix For: 5.5.0.Final
>
>
> When i use to create rules on Guided editor, it can't save.
> For example, my entity is a order entity. It have some keys.
> Entity class : Order(id, ...so on..)
> Entity class : OrderId(baseDate, orderId)
> Keys : baseDate, orderId
> It generated from hibernate generation's classes.
> I created a rule on Guided editor
> When
>         order : Order(id.baseDate >= '...' && id.baseDate <= '..')
> Then
>          ....................
> If i created this rule on Guvnor's guided editor, it could not save.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 16:50:28 2014
From: issues at jboss.org (Dennis Lee (JIRA))
Date: Thu, 23 Jan 2014 16:50:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-415) Guvnor guided editor can't
 save when composite key's condition
In-Reply-To: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530243.1390512824000.10081.1390513828668@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lee updated DROOLS-415:
------------------------------

    Attachment: 1.png

    
> Guvnor guided editor can't save when composite key's condition
> --------------------------------------------------------------
>
>                 Key: DROOLS-415
>                 URL: https://issues.jboss.org/browse/DROOLS-415
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows
>            Reporter: Dennis Lee
>            Assignee: Mark Proctor
>             Fix For: 5.5.0.Final
>
>         Attachments: 1.png
>
>
> When i use to create rules on Guided editor, it can't save.
> For example, my entity is a order entity. It have some keys.
> Entity class : Order(id, ...so on..)
> Entity class : OrderId(baseDate, orderId)
> Keys : baseDate, orderId
> It generated from hibernate generation's classes.
> I created a rule on Guided editor
> When
>         order : Order(id.baseDate >= '...' && id.baseDate <= '..')
> Then
>          ....................
> If i created this rule on Guvnor's guided editor, it could not save.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 16:52:28 2014
From: issues at jboss.org (Dennis Lee (JIRA))
Date: Thu, 23 Jan 2014 16:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-415) Guvnor guided editor can't
 save when composite key's condition
In-Reply-To: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530243.1390512824000.10084.1390513948561@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lee updated DROOLS-415:
------------------------------

    Description: 
When i use to create rules on Guided editor, it can't save.

For example, my entity is a order entity. It have some keys.

Entity class : MailMail(id, ...so on..)
Entity class : MailMailId(baseDate, mailLogId)
Keys : baseDate, mailLogId

It generated from hibernate generation's classes.

I created a rule on Guided editor

When
        order : Order(id.baseDate >= '...' && id.baseDate <= '..')
Then
         ....................

If i created this rule on Guvnor's guided editor, it could not save.





  was:
When i use to create rules on Guided editor, it can't save.

For example, my entity is a order entity. It have some keys.

Entity class : Order(id, ...so on..)
Entity class : OrderId(baseDate, orderId)
Keys : baseDate, orderId

It generated from hibernate generation's classes.

I created a rule on Guided editor

When
        order : Order(id.baseDate >= '...' && id.baseDate <= '..')
Then
         ....................

If i created this rule on Guvnor's guided editor, it could not save.






    
> Guvnor guided editor can't save when composite key's condition
> --------------------------------------------------------------
>
>                 Key: DROOLS-415
>                 URL: https://issues.jboss.org/browse/DROOLS-415
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows
>            Reporter: Dennis Lee
>            Assignee: Mark Proctor
>             Fix For: 5.5.0.Final
>
>         Attachments: 1.png
>
>
> When i use to create rules on Guided editor, it can't save.
> For example, my entity is a order entity. It have some keys.
> Entity class : MailMail(id, ...so on..)
> Entity class : MailMailId(baseDate, mailLogId)
> Keys : baseDate, mailLogId
> It generated from hibernate generation's classes.
> I created a rule on Guided editor
> When
>         order : Order(id.baseDate >= '...' && id.baseDate <= '..')
> Then
>          ....................
> If i created this rule on Guvnor's guided editor, it could not save.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 16:52:28 2014
From: issues at jboss.org (Dennis Lee (JIRA))
Date: Thu, 23 Jan 2014 16:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-415) Guvnor guided editor can't
 save when composite key's condition
In-Reply-To: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530243.1390512824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530243.1390512824000.10086.1390513948638@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lee updated DROOLS-415:
------------------------------

    Description: 
When i use to create rules on Guided editor, it can't save.

For example, my entity is a order entity. It have some keys.

Entity class : MailMail(id, ...so on..)
Entity class : MailMailId(baseDate, mailLogId)
Keys : baseDate, mailLogId

It generated from hibernate generation's classes.

I created a rule on Guided editor

When
        mailMail : MailMail(id.baseDate >= '...' && id.baseDate <= '..')
Then
         ....................

If i created this rule on Guvnor's guided editor, it could not save.





  was:
When i use to create rules on Guided editor, it can't save.

For example, my entity is a order entity. It have some keys.

Entity class : MailMail(id, ...so on..)
Entity class : MailMailId(baseDate, mailLogId)
Keys : baseDate, mailLogId

It generated from hibernate generation's classes.

I created a rule on Guided editor

When
        order : Order(id.baseDate >= '...' && id.baseDate <= '..')
Then
         ....................

If i created this rule on Guvnor's guided editor, it could not save.






    
> Guvnor guided editor can't save when composite key's condition
> --------------------------------------------------------------
>
>                 Key: DROOLS-415
>                 URL: https://issues.jboss.org/browse/DROOLS-415
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows
>            Reporter: Dennis Lee
>            Assignee: Mark Proctor
>             Fix For: 5.5.0.Final
>
>         Attachments: 1.png
>
>
> When i use to create rules on Guided editor, it can't save.
> For example, my entity is a order entity. It have some keys.
> Entity class : MailMail(id, ...so on..)
> Entity class : MailMailId(baseDate, mailLogId)
> Keys : baseDate, mailLogId
> It generated from hibernate generation's classes.
> I created a rule on Guided editor
> When
>         mailMail : MailMail(id.baseDate >= '...' && id.baseDate <= '..')
> Then
>          ....................
> If i created this rule on Guvnor's guided editor, it could not save.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 23 16:58:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Jan 2014 16:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2773) ClientConfigurationImpl
 should not translate IP address to host name
In-Reply-To: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529691.1389963183000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529691.1389963183000.10098.1390514308558@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938412#comment-12938412 ] 

RH Bugzilla Integration commented on WFLY-2773:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1054776|https://bugzilla.redhat.com/show_bug.cgi?id=1054776] from POST to MODIFIED
                
> ClientConfigurationImpl should not translate IP address to host name
> --------------------------------------------------------------------
>
>                 Key: WFLY-2773
>                 URL: https://issues.jboss.org/browse/WFLY-2773
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> When creating a ModelControllerClient and passing in an IP address, ClientConfigurationImpl internally translates it to a host name, like here:
> {noformat}
> public static ModelControllerClientConfiguration create(final InetAddress address, final int port) {
>         return new ClientConfigurationImpl(address.getHostName(), port, null, null, null, createDefaultExecutor(), true, null);
>     }
> {noformat}
> Later on, when the client connects, it is translated via DNS back to an IP address. This is not only unnecessary, but in some situations, it is wrong.
> Consider a Windows machine having two IP addresses ,A and B, on one network interface, where only A is pointed at by a DNS record. 
> - Run AS testsuite and pass it the address B as the node0 property, AS will bind itself to this address.
> - Now when a test creates a ModelControllerClient using IP address B, the address B will get translated to the host name, even though B is not in the DNS. The resolving works this way on a Windows machine.
> - During the connection, the host name will get resolved by DNS to address A and the test will try to connect through address A. The connection will be refused, or worse, might connect to another instance on the same machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 01:58:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Fri, 24 Jan 2014 01:58:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.10458.1390546709395@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938458#comment-12938458 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

I got to test it this night and unfortunately it does not work. Still having three threads causing 100% cpu load.

I made a new stacktrace and I think I figured out, why they looked strange to you, David. I'll attach an fresh stacktrace made with '$ jstack -F -m 1295'.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 01:58:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Fri, 24 Jan 2014 01:58:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.10466.1390546709815@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias Richter updated WFLY-2778:
-----------------------------------

    Attachment: stacktrace-new.out

    
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 03:22:28 2014
From: issues at jboss.org (Chao Wang (JIRA))
Date: Fri, 24 Jan 2014 03:22:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2808) Method typo in
	BasicIIOPInvocationTestCase
In-Reply-To: <JIRA.12530263.1390551701505@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530263.1390551701505@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530263.1390551701505.10564.1390551748585@jira02.app.mwc.hst.phx2.redhat.com>

Chao Wang created WFLY-2808:
-------------------------------

             Summary: Method typo in BasicIIOPInvocationTestCase
                 Key: WFLY-2808
                 URL: https://issues.jboss.org/browse/WFLY-2808
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.CR1
            Reporter: Chao Wang
            Assignee: Chao Wang
            Priority: Trivial
             Fix For: 8.0.0.Final


Correct method typo in BasicIIOPInvocationTestCase, and HandleWrapper should be serializable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 03:28:28 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 24 Jan 2014 03:28:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-413) Help content for this
 Eclipse plugin version appears missing
In-Reply-To: <JIRA.12530044.1390337964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530044.1390337964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530044.1390337964000.10576.1390552108914@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-413:
-------------------------------

    Issue Type: Task  (was: Bug)

    
> Help content for this Eclipse plugin version appears missing
> ------------------------------------------------------------
>
>                 Key: DROOLS-413
>                 URL: https://issues.jboss.org/browse/DROOLS-413
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Windows 7, Eclipse Juno, JDK 1.6
>            Reporter: Rebecca Biller
>            Assignee: Mark Proctor
>              Labels: Help, Online, Plugins
>
> Our software was previously on Drools 3.3 and we upgraded to Drools 5.5. It is close to completion of testing, and QA has found that the online help doesn't work for Drools as it did with the previous Eclipse plugin. It seems the Drools plugin help folder is empty. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 03:46:28 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 24 Jan 2014 03:46:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Drools invokes superclass
	static method
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.10611.1390553188570@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-410:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Drools invokes superclass static method
> ---------------------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mario Fusco
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Fri Jan 24 03:50:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 03:50:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2633) Cannot use deployments with
 same runtime-name in a domain
In-Reply-To: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527605.1386720363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527605.1386720363000.10614.1390553428516@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938473#comment-12938473 ] 

RH Bugzilla Integration commented on WFLY-2633:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1039699|https://bugzilla.redhat.com/show_bug.cgi?id=1039699] from ON_QA to VERIFIED
                
> Cannot use deployments with same runtime-name in a domain
> ---------------------------------------------------------
>
>                 Key: WFLY-2633
>                 URL: https://issues.jboss.org/browse/WFLY-2633
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The check for duplicate runtime-name in a server group on startup is too aggressive.  It is incorrectly throwing an error on startup if there are any duplicate runtime-names in the whole domain, instead of just in a single server group.
> Steps to Reproduce:
> 1.  Start a single HC/DC
> 2.  deploy --name=foo1 --runtime-name=bar --disabled testfile
> 3.  deploy --name=foo2 --runtime-name=bar --disabled testfile
> 4.  restart the DC/HC
> Actual results:
> JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> ...
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9]
> ...
> Message: JBAS014664: An element of this type named 'bar' has already been declared
> Expected results:
> No errors

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 04:50:29 2014
From: issues at jboss.org (Matthias Bosshard (JIRA))
Date: Fri, 24 Jan 2014 04:50:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.10709.1390557029545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938493#comment-12938493 ] 

Matthias Bosshard commented on WFLY-2778:
-----------------------------------------

I had the same issue and it's gone with the fix for this bug: [https://issues.jboss.org/browse/XNIO-215]
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 04:56:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Jan 2014 04:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1783) FD_ALL2: new failure
 detection protocol without timestamps
In-Reply-To: <JIRA.12530269.1390557295522@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530269.1390557295522@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530269.1390557295522.10720.1390557388538@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1783:
------------------------------

             Summary: FD_ALL2: new failure detection protocol without timestamps
                 Key: JGRP-1783
                 URL: https://issues.jboss.org/browse/JGRP-1783
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


System.currentTimeMillis() is used frequently in FD_ALL. Here's the design of a new protocol that does without it:
* boolean {{skip_heartbeat}}, {{heartbeat_received}} (per member)
* Sender: when sending a multicast message, set {{skip_heartbeat}} to true if not true
* Sender: send a (multicast) heartbeat every {{interval}} ms unless {{skip_heartbeat}} is true (set it to false if true)
* Receiver: when receiving a message or heartbeat from sender P, set P's {{heartbeat_received}} to true (CAS operation)
* Receiver: check heartbeats table every {{timeout}} ms. Suspect any member P whose {{heartbeat_received}} is false


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 05:32:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 05:32:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-705) Implement a User Agent and
 Remote Address Filter for the HTTP Management Interface
In-Reply-To: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12450792.1319827535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450792.1319827535000.10750.1390559548858@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938498#comment-12938498 ] 

Darran Lofthouse commented on WFLY-705:
---------------------------------------

Yes following on from a few discussions we have had recently we need to expand quite a bit on the configuration of the management interfaces, this is one aspect, cross origin resource sharing is another, enhancements to security is another, there are a few others as well but essentially yes it all should happen under WFLY-2635.
                
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-705
>                 URL: https://issues.jboss.org/browse/WFLY-705
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Andre Dietisheim
>             Fix For: 8.0.0.CR1
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 05:34:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 05:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Drools invokes superclass
	static method
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.10754.1390559668939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-410:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1057550

    
> Drools invokes superclass static method
> ---------------------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mario Fusco
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Fri Jan 24 05:34:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 05:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Drools invokes superclass
	static method
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.10757.1390559669041@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938499#comment-12938499 ] 

RH Bugzilla Integration commented on DROOLS-410:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1057550|https://bugzilla.redhat.com/show_bug.cgi?id=1057550] from NEW to ASSIGNED
                
> Drools invokes superclass static method
> ---------------------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mario Fusco
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Fri Jan 24 05:38:28 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 24 Jan 2014 05:38:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Drools invokes superclass
	static method
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.10767.1390559908625@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938501#comment-12938501 ] 

Mario Fusco commented on DROOLS-410:
------------------------------------

For how this problem has been reported it seems to be a bug of the constraint jitting process. However I find a simpler use case (that I am pasting below) showing that in some cases this problem is present also before the constraints jitter kicks in.

{code}
    public static class ARef {
        public static int getSize(String s) {
            return 0;
        }
    }

    public static class BRef extends ARef {
        public static int getSize(String s) {
            return s.length();
        }
    }

    @Test
    public void testJittingConstraintInvokingStaticMethod() throws Exception {
        // DROOLS-410
        String str =
                "dialect \"mvel\"\n" +
                "import org.drools.compiler.integrationtests.Misc2Test.ARef\n" +
                "import org.drools.compiler.integrationtests.Misc2Test.BRef\n" +
                "\n" +
                "global java.util.List list;\n" +
                "\n" +
                "rule R when\n" +
                "    $s : String( length == BRef.getSize(this) )\n" +
                "then\n" +
                "    list.add($s);\n" +
                "end\n";

        KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        List<String> list = new ArrayList<String>();
        ksession.setGlobal("list", list);

        ksession.insert("1234");
        ksession.fireAllRules();

        assertEquals(1, list.size());
    }
{code}
                
> Drools invokes superclass static method
> ---------------------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mario Fusco
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Fri Jan 24 05:40:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 24 Jan 2014 05:40:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-410) Drools invokes superclass
	static method
In-Reply-To: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529976.1390305870000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529976.1390305870000.10780.1390560029212@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-410.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done


The solution for this issue also requires a fix made in mvel. This mean that the fix will be available when the next mvel release (2.1.9.Final) will be out.
                
> Drools invokes superclass static method
> ---------------------------------------
>
>                 Key: DROOLS-410
>                 URL: https://issues.jboss.org/browse/DROOLS-410
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Micha?l Mathieu
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
>     private String ref;
>     protected ARef(String ref) {
>         this.ref = ref;
>     }
>     public static ARef valueOf(String ref) {
>         System.out.println("ARef> " + ref);
>         return new ARef(ref);
>     }
>     @Override
>     public String toString() {
>         return ref;
>     }
>     @Override
>     public int hashCode() {
>         final int prime = 31;
>         int result = 1;
>         result = prime * result + ((ref == null) ? 0 : ref.hashCode());
>         return result;
>     }
>     @Override
>     public boolean equals(Object obj) {
>         if (this == obj) return true;
>         if (obj == null) return false;
>         if (getClass() != obj.getClass()) return false;
>         ARef other = (ARef) obj;
>         if (ref == null) {
>             if (other.ref != null) return false;
>         } else if (!ref.equals(other.ref)) return false;
>         return true;
>     }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
>     private BRef(String ref) {
>         super(ref);
>     }
>     public static BRef valueOf(String ref) {
>         System.out.println("BRef> " + ref);
>         return new BRef(ref);
>     }
> }
> {code}
> {code}
> package test;
> public class Criteria {
>     private BRef ref;
>     private boolean ok = false;
>     public Criteria(BRef ref) {
>         this.ref = ref;
>     }
>     public BRef getRef() {
>         return ref;
>     }
>     public boolean isOk() {
>         return ok;
>     }
>     public void setOk() {
>         this.ok = true;
>     }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
>     private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
>             + "  criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + "  criteria.setOk();\r\n" + "end";
>     public static void main(String[] args) {
>         System.out.println(DRL);
>         try {
>             PackageBuilder builder = new PackageBuilder();
>             builder.addPackageFromDrl(new StringReader(DRL));
>             Package pkg = builder.getPackage();
>             RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>             ruleBase.addPackage(pkg);
>             for (int i = 0; i < 1000; i++) {
>                 Criteria criteria = new Criteria(BRef.valueOf("toto"));
>                 StatelessSession session = ruleBase.newStatelessSession();
>                 session.execute(criteria);
>                 System.out.println("[" + i + "] " + criteria.isOk());
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
>   criteria:Criteria(ref == BRef.valueOf("toto"))
> then
>   criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {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 issues at jboss.org  Fri Jan 24 06:08:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 06:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2510) Add CLI command to display
 information about current connection.
In-Reply-To: <JIRA.12525107.1384433192000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525107.1384433192000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525107.1384433192000.10816.1390561708810@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2510:
-----------------------------------

        Parent:     (was: WFLY-1597)
    Issue Type: Enhancement  (was: Sub-task)

    
> Add CLI command to display information about current connection.
> ----------------------------------------------------------------
>
>                 Key: WFLY-2510
>                 URL: https://issues.jboss.org/browse/WFLY-2510
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Would be useful for a single command to display information about the current connection.
> Definitely information about SSL, certificates, authenticated user, address etc...
> Could also obtain other common info from 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 issues at jboss.org  Fri Jan 24 06:08:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 06:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2510) Add CLI command to display
 information about current connection.
In-Reply-To: <JIRA.12525107.1384433192000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525107.1384433192000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525107.1384433192000.10819.1390561708961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2510:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Add CLI command to display information about current connection.
> ----------------------------------------------------------------
>
>                 Key: WFLY-2510
>                 URL: https://issues.jboss.org/browse/WFLY-2510
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Would be useful for a single command to display information about the current connection.
> Definitely information about SSL, certificates, authenticated user, address etc...
> Could also obtain other common info from 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 issues at jboss.org  Fri Jan 24 06:08:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Jan 2014 06:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1783) FD_ALL2: new failure
 detection protocol without timestamps
In-Reply-To: <JIRA.12530269.1390557295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530269.1390557295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530269.1390557295000.10822.1390561709119@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1783.
----------------------------

    Resolution: Done

    
> FD_ALL2: new failure detection protocol without timestamps
> ----------------------------------------------------------
>
>                 Key: JGRP-1783
>                 URL: https://issues.jboss.org/browse/JGRP-1783
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> System.currentTimeMillis() is used frequently in FD_ALL. Here's the design of a new protocol that does without it:
> * boolean {{skip_heartbeat}}, {{heartbeat_received}} (per member)
> * Sender: when sending a multicast message, set {{skip_heartbeat}} to true if not true
> * Sender: send a (multicast) heartbeat every {{interval}} ms unless {{skip_heartbeat}} is true (set it to false if true)
> * Receiver: when receiving a message or heartbeat from sender P, set P's {{heartbeat_received}} to true (CAS operation)
> * Receiver: check heartbeats table every {{timeout}} ms. Suspect any member P whose {{heartbeat_received}} is false

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 06:08:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 06:08:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2490) Connecting using
 https-remoting times out and leaves thread within CLI spinning at 100%
In-Reply-To: <JIRA.12524819.1384192055000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524819.1384192055000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524819.1384192055000.10824.1390561709178@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938511#comment-12938511 ] 

Darran Lofthouse commented on WFLY-2490:
----------------------------------------

A fix for XNIO-215 is on it's way, no further work should be required within WildFly.

                
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2490
>                 URL: https://issues.jboss.org/browse/WFLY-2490
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 06:12:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 06:12:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2207) CLI Unable to connect using
 https-remoting address.
In-Reply-To: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502036.1380735356000.10830.1390561948675@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2207.
------------------------------------

    Resolution: Out of Date


Subsequent re-factoring has addressed this.
                
> CLI Unable to connect using https-remoting address.
> ---------------------------------------------------
>
>                 Key: WFLY-2207
>                 URL: https://issues.jboss.org/browse/WFLY-2207
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> The CLI is failing to connect over https with the following: -
> {code}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {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 issues at jboss.org  Fri Jan 24 07:02:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 24 Jan 2014 07:02:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1763) TimeService
In-Reply-To: <JIRA.12528486.1388485586000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528486.1388485586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528486.1388485586000.10849.1390564948890@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938516#comment-12938516 ] 

Bela Ban commented on JGRP-1763:
--------------------------------

* TCPConnectionMap$TCPConnection now uses TimeService
* UNICAST3 as well when sending and receiving messages
                
> TimeService
> -----------
>
>                 Key: JGRP-1763
>                 URL: https://issues.jboss.org/browse/JGRP-1763
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> New service which provides wall clock time at a coarse (configurable) granularity. 
> Motivation: {{System.currentTimeMillis()}} or {{System.nanoTime()}} is sometimes called frequently, e.g. by {{TCPConnectionMap$TCPConnection.updateLastAccessed()}} or in FD/FD_ALL. This has a cost, especially when a lock is held (system calls while a lock is held cause preemption and the thread losing its time slice).
> However, the 2 examples above don't need the exact time, but an approximation of it is OK.
> GOALS:
> * Provide a time service which returns  the last cached value of {{System.timeCurrentMillis()}}
> * This is a quick and efficient call
> * {{TimeService}} registers a timer task which updates its internal cached value every N milliseconds (configurable), e.g. every 500 ms
> BENEFIT:
> For example, in TCPConnection, the timestamp is updated whenever we send or receive a message from the peer. The timestamp is used to expire and close a connection (if configured), and can be updated 100'000 times a second. If the time service provided the current time in ms every 500ms, then {{System.currentTimeMillis()}} would only be called 2 times during a second instead of 100'000 times !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 07:30:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 07:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.10902.1390566628831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938528#comment-12938528 ] 

RH Bugzilla Integration commented on DROOLS-411:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1056599|https://bugzilla.redhat.com/show_bug.cgi?id=1056599] from MODIFIED to ON_QA
                
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Fri Jan 24 08:06:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 08:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2256) Add a TRACE level category
 for the operations used to start a server.
In-Reply-To: <JIRA.12502422.1381225020000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502422.1381225020000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502422.1381225020000.10948.1390568788826@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2256:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Add a TRACE level category for the operations used to start a server.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2256
>                 URL: https://issues.jboss.org/browse/WFLY-2256
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Logging
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server.
> From a development perspective this is useful for double checking the operations are as we expect.
> From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI 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 issues at jboss.org  Fri Jan 24 08:06:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 08:06:29 -0500 (EST)
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.10952.1390568789033@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: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Vault.sh logging improvements
> -----------------------------
>
>                 Key: WFLY-2100
>                 URL: https://issues.jboss.org/browse/WFLY-2100
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Fri Jan 24 08:06:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Jan 2014 08:06:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1014) Enable CORS
In-Reply-To: <JIRA.12488815.1365460947000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488815.1365460947000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488815.1365460947000.10955.1390568789134@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1014:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Enable CORS
> -----------
>
>                 Key: WFLY-1014
>                 URL: https://issues.jboss.org/browse/WFLY-1014
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> We've been prototyping an alternative distribution channel for the console and have setup a demo that leverages the mozilla app store to deliver the AS7 web console to users:
> https://marketplace.firefox.com/app/kea/?src=mkt-search
> For this to work the AS needs to fully support CORS [1]. The general idea is that you can retrieve the console through a marketplace like the mozilla one (chrome would be another alternative) and connect to any domain controller, wether it runs locally or remotely.
> If want to give it shot, point four firefox browser to the marketplace URL, launch the app and connect to our CORS demo instance that runs on EC2:
> http://as7-preview.dyndns.org:9990
> user: admin
> pass: webstore123!
> [1] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 08:18:28 2014
From: issues at jboss.org (xiang yingbing (JIRA))
Date: Fri, 24 Jan 2014 08:18:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2797) Update hibernate to 4.3.1 or
 above according to HHH-8756
In-Reply-To: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530173.1390447989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530173.1390447989000.11015.1390569508974@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938548#comment-12938548 ] 

xiang yingbing commented on WFLY-2797:
--------------------------------------

Thank you  very much!
:)
                
> Update hibernate to 4.3.1 or above according to HHH-8756
> --------------------------------------------------------
>
>                 Key: WFLY-2797
>                 URL: https://issues.jboss.org/browse/WFLY-2797
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.CR1
>         Environment: 8.0.0.CR1
>            Reporter: xiang yingbing
>            Assignee: Scott Marlow
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> 1. The bug description:
>     https://community.jboss.org/message/851147#851147
> Named query with JPA entitymanager throws exception: java.lang.IllegalStateException: Illegal attempt to set lock mode on a non-SELECT query
> 2. This bug is fixed since hibernate-4.3.1:
> https://hibernate.atlassian.net/browse/HHH-8756
> So please Update hibernate to 4.3.1 or above according to HHH-8756 for wildfly-8.0.0-Final.
> NOTE: I downloaded the latest nightly-build version, found that the hibernate version is still 4.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 issues at jboss.org  Fri Jan 24 08:22:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 08:22:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-385) KModules get added twice
In-Reply-To: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528350.1387663007000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528350.1387663007000.11026.1390569748664@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938552#comment-12938552 ] 

RH Bugzilla Integration commented on DROOLS-385:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1046095|https://bugzilla.redhat.com/show_bug.cgi?id=1046095] from ON_QA to VERIFIED
                
> KModules get added twice
> ------------------------
>
>                 Key: DROOLS-385
>                 URL: https://issues.jboss.org/browse/DROOLS-385
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mario Fusco
>
> The class loader is returning duplicate entries, as it incorrectly implements:
>     @Override
>     protected Enumeration<URL> findResources(String name) throws IOException {
>         return getParent().getResources(name);
>     }
> Deleting this method resolves the problem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 08:44:29 2014
From: issues at jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 24 Jan 2014 08:44:29 -0500 (EST)
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.11056.1390571069147@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated WFLY-2057:
---------------------------------------

    Forum Reference: https://community.jboss.org/message/808212#808212

    
> 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
>      Security Level: Public(Everyone can see) 
>          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 issues at jboss.org  Fri Jan 24 09:12:29 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 24 Jan 2014 09:12:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.11129.1390572749225@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFLY-880:
-----------------------------------

    Assignee: Richard Opalka  (was: Alexey Loubyansky)

    
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 09:14:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 09:14:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2760) Intermittent failure of
 ExternalContextBindingTestCase
In-Reply-To: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529570.1389865466000.11155.1390572868828@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938569#comment-12938569 ] 

RH Bugzilla Integration commented on WFLY-2760:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1054106|https://bugzilla.redhat.com/show_bug.cgi?id=1054106] from POST to MODIFIED
                
>  Intermittent failure of ExternalContextBindingTestCase
> -------------------------------------------------------
>
>                 Key: WFLY-2760
>                 URL: https://issues.jboss.org/browse/WFLY-2760
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Minor
>
> The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.
> It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 09:28:28 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 24 Jan 2014 09:28:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.11239.1390573708818@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938581#comment-12938581 ] 

Richard Opalka commented on WFLY-880:
-------------------------------------

Yes, it is possible that when you have your break points in AbstractDeploymentUnitService.DeploymentServiceListener,
you might see some missing services to be registered with servicesMissingDependencies. This variable is modified when 
listener is obtaining transition notifications from MSC state machine and if you're inspecting it while MSC transitions are
still in progress, it's expected behaviour then. But once you'll free these breakpoint, all the locks will be freed and
MSC services will transition to they final REST states.

Can you reproduce this issue once server is up and running, or just sometimes if and only if server is booting?
I'd say if you're able to reproduce it only during server bootstrap process I'd say it's kinda expected behaviour.
The question I'd ask further here is if server is booting and someone tries to display deployment-info, shouldn't this
be blocked or disabled (somehow) during the server boot (until the server is up and running)?
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 09:30:28 2014
From: issues at jboss.org (Matthias Bosshard (JIRA))
Date: Fri, 24 Jan 2014 09:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1376)
 HttpServletResponseImpl.getWriter() cannot be called: getOutputStream()
 already called
In-Reply-To: <JIRA.12492418.1369219332000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492418.1369219332000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492418.1369219332000.11244.1390573828628@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938582#comment-12938582 ] 

Matthias Bosshard commented on WFLY-1376:
-----------------------------------------

I have the same issue, but with WildFly 8 CR1, is this broken again?

15:24:39,886 ERROR [io.undertow.request] (default task-9) UT005023: Exception handling request to /index.html: javax.servlet.ServletException: UT010006: Cannot call getWriter(), getOutputStream() already called
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) [jsf-api-2.1.27.jar:2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]

                
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-1376
>                 URL: https://issues.jboss.org/browse/WFLY-1376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
>   <error-page>
>     <error-code>404</error-code>
>     <location>/error/pageNotFound.jsf</location>
>   </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	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 issues at jboss.org  Fri Jan 24 10:26:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 10:26:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-411) Memory leak in nurse
 rostering example for dataset medium01, due to a bug in Drools
In-Reply-To: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529949.1390296250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529949.1390296250000.11364.1390577188696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938598#comment-12938598 ] 

RH Bugzilla Integration commented on DROOLS-411:
------------------------------------------------

Luk?? Petrovick? <lpetrovi at redhat.com> changed the Status of [bug 1056599|https://bugzilla.redhat.com/show_bug.cgi?id=1056599] from ON_QA to VERIFIED
                
> Memory leak in nurse rostering example for dataset medium01, due to a bug in Drools
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-411
>                 URL: https://issues.jboss.org/browse/DROOLS-411
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: memory_leak_nurse_rostering.png, memory_leak_nurse_rostering1.png
>
>
> See screenshots
> Eventually leads to (but that stacktrace is misleading to the true case):
> {code}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 	at org.drools.core.reteoo.NotNode.createLeftTuple(NotNode.java:127) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:152) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:958) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:932) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:232) ~[drools-core-6.1.0-20140109.225128-430.jar:6.1.0-SNAPSHOT]
> 	at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:98) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.calculateScore(DefaultSolverScope.java:101) ~[classes/:na]
> 	at org.optaplanner.core.impl.phase.AbstractSolverPhaseScope.calculateScore(AbstractSolverPhaseScope.java:124) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.processMove(LocalSearchDecider.java:147) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:134) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:107) ~[classes/:na]
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchSolverPhase.solve(DefaultLocalSearchSolverPhase.java:62) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190) ~[classes/:na]
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:155) ~[classes/:na]
> 	at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:268) ~[classes/:na]
> 	at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveAction$1.run(SolverAndPersistenceFrame.java:278) ~[classes/:na]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
> {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 issues at jboss.org  Fri Jan 24 10:28:29 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Fri, 24 Jan 2014 10:28:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.11383.1390577309469@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Dolphy updated JBMETA-371:
--------------------------------

    Affects Version/s:     (was: 7.0.4)

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 10:28:29 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Fri, 24 Jan 2014 10:28:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.11385.1390577309533@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Dolphy updated JBMETA-371:
--------------------------------

    Affects Version/s: 7.0.4

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 10:42:29 2014
From: issues at jboss.org (Ramil Israfilov (JIRA))
Date: Fri, 24 Jan 2014 10:42:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.11428.1390578149112@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938609#comment-12938609 ] 

Ramil Israfilov commented on WFLY-880:
--------------------------------------

actually once we hit that it is on the same FAIL state even after server startup.
The only way to get rid of it is to restart jboss.
But it if you do multiple restarts it still can happen, that deployment will stay in FAILED state even all of it's services are available and application behaves correctly. Also in server.log file there is no any error about failed deployment. It is just that call to CLI which reports FAILED state
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:00:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jan 2014 11:00:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.11461.1390579229420@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938615#comment-12938615 ] 

Brian Stansberry commented on WFLY-880:
---------------------------------------

Is this a problem with WildFly 8.0.0.CR1? There have been some pretty significant changes in the service container stability tracking that's relevant to this attribute since this issue was filed. So it may be out of date in WildFly.
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:14:28 2014
From: issues at jboss.org (Frank Cornelis (JIRA))
Date: Fri, 24 Jan 2014 11:14:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046864@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046864@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046864.11500.1390580068763@jira02.app.mwc.hst.phx2.redhat.com>

Frank Cornelis created WFLY-2809:
------------------------------------

             Summary: JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
                 Key: WFLY-2809
                 URL: https://issues.jboss.org/browse/WFLY-2809
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
    Affects Versions: 8.0.0.CR1
            Reporter: Frank Cornelis
            Assignee: David Lloyd
            Priority: Blocker


Calling
{code}
PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
{code}
within a @Stateless session bean gives an exception.

I've created an integration test to reproduce 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 issues at jboss.org  Fri Jan 24 11:16:29 2014
From: issues at jboss.org (Frank Cornelis (JIRA))
Date: Fri, 24 Jan 2014 11:16:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.11503.1390580189950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Cornelis updated WFLY-2809:
---------------------------------

    Attachment: 0001-integration-test-for-JACC-PolicyContext.patch


Integration test to reproduce this case.
                
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: David Lloyd
>            Priority: Blocker
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Fri Jan 24 11:22:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 24 Jan 2014 11:22:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.11535.1390580549549@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2809:
------------------------------

    Assignee: Stefan Guilhen  (was: David Lloyd)

    
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: Stefan Guilhen
>            Priority: Blocker
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Fri Jan 24 11:36:30 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 24 Jan 2014 11:36:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.11598.1390581390108@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938633#comment-12938633 ] 

Tomaz Cerar commented on WFLY-2641:
-----------------------------------

[~thomas.diesler] we (wildfly team) did one off release of 1.1.2.Final which is called 1.1.2.Final-wildfly-1
it has my NPE "fix" in that helps get our testsuite mostly working again.
                
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Aslak Knutsen
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Fri Jan 24 11:40:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 11:40:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-975) Deployment replace causes
 invalid state in DUP
In-Reply-To: <JIRA.12487614.1363781438000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487614.1363781438000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487614.1363781438000.11604.1390581628900@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938634#comment-12938634 ] 

RH Bugzilla Integration commented on WFLY-975:
----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 924562|https://bugzilla.redhat.com/show_bug.cgi?id=924562] from NEW to MODIFIED
                
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
>                 Key: WFLY-975
>                 URL: https://issues.jboss.org/browse/WFLY-975
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: Thomas Diesler
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO  [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO  [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO  [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO  [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> 	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.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> 	... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 11:42:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 24 Jan 2014 11:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2777) JNDI external context binding
 doesn't properly set a module class loader
In-Reply-To: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529837.1390213800000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529837.1390213800000.11619.1390581748772@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938638#comment-12938638 ] 

RH Bugzilla Integration commented on WFLY-2777:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1057168|https://bugzilla.redhat.com/show_bug.cgi?id=1057168] from POST to MODIFIED
                
> JNDI external context binding doesn't properly set a module class loader
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2777
>                 URL: https://issues.jboss.org/browse/WFLY-2777
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Final
>
>
> The current implementation of JNDI external context binding takes a module class loader if based by a module for loading a initialContextClassName only (note that this initialContextClassName is one of InitialContext, InitialDirContext or InitialLdapContext). While it rather needs to switch TCCL to the module class loader to be available when trying to get a new instance of it at line 87, see the snippet below. As this is the moment when it constructs a new initial context from a factory class given by environment properties.
> {code:java|title=naming/src/main/java/org/jboss/as/naming/ExternalContextObjectFactory.java}
> 83             Module module = Module.getBootModuleLoader().loadModule(ModuleIdentifier.fromString(initialContextModule));
> 84             loader = module.getClassLoader();
> 85             initialContextClass = Class.forName(initialContextClassName, true, module.getClassLoader());
> 86             Constructor ctor = initialContextClass.getConstructor(Hashtable.class);
> 87             context = (Context) ctor.newInstance(newEnvironment);
> {code}
> Due to this issue the binding fails with an exception as follows:
> {noformat}
> 17:02:46,740 ERROR [stderr] (default task-1) Caused by: java.lang.reflect.InvocationTargetException
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 17:02:46,740 ERROR [stderr] (default task-1)   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 17:02:46,741 ERROR [stderr] (default task-1)   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 17:02:46,741 ERROR [stderr] (default task-1)   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> 17:02:46,742 ERROR [stderr] (default task-1)   at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:46)
> 17:02:46,743 ERROR [stderr] (default task-1)   at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> 17:02:46,743 ERROR [stderr] (default task-1)   ... 36 more
> 17:02:46,744 ERROR [stderr] (default task-1) Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory org.jboss.security.jndi.JndiLoginInitialContextFactory from classloader ModuleClassLoader for Module &quot;deployment.messagesender.war:main&quot; from Service Module Loader
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)
> 17:02:46,744 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,745 ERROR [stderr] (default task-1)   at javax.naming.directory.InitialDirContext.&lt;init&gt;(InitialDirContext.java:101)
> 17:02:46,745 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContext.&lt;init&gt;(InitialContext.java:90)
> 17:02:46,746 ERROR [stderr] (default task-1)   at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
> 17:02:46,746 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.init(InitialContext.java:242)
> 17:02:46,747 ERROR [stderr] (default task-1)   at javax.naming.InitialContext.&lt;init&gt;(InitialContext.java:216)
> 17:02:46,747 ERROR [stderr] (default task-1)   ... 43 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 issues at jboss.org  Fri Jan 24 11:42:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 24 Jan 2014 11:42:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1383) Disable pooling of stateless
 EJBs by default
In-Reply-To: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492528.1369290890000.11624.1390581749037@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1383.
----------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> Disable pooling of stateless EJBs by default
> --------------------------------------------
>
>                 Key: WFLY-1383
>                 URL: https://issues.jboss.org/browse/WFLY-1383
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Cheng Fang
>             Fix For: 8.0.0.Final
>
>
> A certain use case has shown that it's perhaps better to disable pooling of EJB stateless bean, by default. In AS7 we have always allowed disabling the pooling but we hadn't made it the default since we thought it might affect applications which have SLSBs with heavy @PostConstruct.
> A recent discussion has suggested that we disable the pooling by default and individual applications can enable it and set the relevant pool size themselves. The reasoning has been that, the default pool size that we ship with, anyway will have to be tweaked by the users since we can't really guess what an ideal pool size 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 issues at jboss.org  Fri Jan 24 12:30:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 12:30:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-781) Release PicketBox
	4.0.20.Beta4
In-Reply-To: <JIRA.12528805.1389137623000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528805.1389137623000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528805.1389137623000.11800.1390584629055@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed SECURITY-781.
-----------------------------------

    Resolution: Done


PicketBox 4.0.20.Beta4 has been released.
                
> Release PicketBox 4.0.20.Beta4
> ------------------------------
>
>                 Key: SECURITY-781
>                 URL: https://issues.jboss.org/browse/SECURITY-781
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 12:34:28 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 12:34:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1130) vault shared key should be
	salted
In-Reply-To: <JIRA.12471119.1343205463000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471119.1343205463000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471119.1343205463000.11813.1390584868786@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen reassigned WFLY-1130:
------------------------------------

    Assignee: Peter Skopek  (was: Stefan Guilhen)

    
> vault shared key should be salted
> ---------------------------------
>
>                 Key: WFLY-1130
>                 URL: https://issues.jboss.org/browse/WFLY-1130
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Gernot P
>            Assignee: Peter Skopek
>
> Actual behaviour:
> (1) create a vault entry with
>      vault attribute value: xxx
>      vault block: y1
>      vault attribute name: z1
> (2) create another vault entry with
>      vault attribute value: xxx
>      vault block: y2
>      vault attribute name: z2
> and you see that vault shared key is the same for entry 1 and entry 2
> feature request:
> two vault entries with same attribute value but different block names and attribute names should have different shared keys

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 12:34:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 12:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1158) add "remove vault entry"
 option to vault tool
In-Reply-To: <JIRA.12471159.1343221728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471159.1343221728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471159.1343221728000.11817.1390584868999@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen reassigned WFLY-1158:
------------------------------------

    Assignee: Peter Skopek  (was: Stefan Guilhen)

    
> add "remove vault entry" option to vault tool 
> ----------------------------------------------
>
>                 Key: WFLY-1158
>                 URL: https://issues.jboss.org/browse/WFLY-1158
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Gernot P
>            Assignee: Peter Skopek
>         Attachments: patch.diff
>
>
> You cannot remove an entry form vault with the vault tool. You can choose only amog following options "0: Store a password  1: Check whether password exists  2: Exit"
> Pleas add "remove password" option to vault tool (vault.sh)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 12:34:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 12:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-814) vault util requests a URL but
 expects an absolute path.
In-Reply-To: <JIRA.12472122.1344531035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472122.1344531035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472122.1344531035000.11830.1390584869653@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen reassigned WFLY-814:
-----------------------------------

    Assignee: Peter Skopek  (was: Stefan Guilhen)

    
> vault util requests a URL but expects an absolute path.
> -------------------------------------------------------
>
>                 Key: WFLY-814
>                 URL: https://issues.jboss.org/browse/WFLY-814
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Peter Skopek
>
> The vault utility asks for a URL to the keystore but then treats it as an absolute path: -
> {code}
> Enter Keystore URL:file:///home/darranl/tmp/vault/vault.keystore
> Enter Keystore password: 
> Enter Keystore password again: 
> Values match
> Enter 8 character salt:abcdefgh
> Enter iteration count as a number (Eg: 44):13
> Exception encountered:Keystore [file:///home/darranl/tmp/vault/vault.keystore] doesn't exist.
> {code}
> Also is there really a need to take the password twice?  That is normally used on setting a new password to ensure it is set correctly, in this case the password could easily be verified against the keystore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 12:34:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 12:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-783) LdapExtLoginModule's
 bindCredential requires vault string to be in a slightly different format
 than other components
In-Reply-To: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529018.1389283872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529018.1389283872000.11833.1390584869818@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen reassigned SECURITY-783:
---------------------------------------

    Assignee: Peter Skopek  (was: Stefan Guilhen)


Peter, can you please take a look into Derek's patch?
                
> LdapExtLoginModule's bindCredential requires vault string to be in a slightly different format than other components
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-783
>                 URL: https://issues.jboss.org/browse/SECURITY-783
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Peter Skopek
>            Priority: Minor
>         Attachments: SECURITY-783.patch
>
>
> The LdapExtLoginModule requires that the vault string used for the bindCredentials not include the '${' prefix and '}' suffix.  This is different than other places in the standalone.xml file where the ${ and } are 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 issues at jboss.org  Fri Jan 24 13:34:29 2014
From: issues at jboss.org (Rob deheer (JIRA))
Date: Fri, 24 Jan 2014 13:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4468) Cannot remove and re-add
 socket-binding group
In-Reply-To: <JIRA.12463690.1334156865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463690.1334156865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463690.1334156865000.12101.1390588469174@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938679#comment-12938679 ] 

Rob deheer commented on AS7-4468:
---------------------------------

Is there a way to start the management server only? Something like this would be ideal. 

domain.sh start-servers=false

I need to be able to start servers in a controlled fashion, verifying that each component is available before starting the next. 

I know the correct way way to accomplish my requirement is to use the jboss deployment descriptors to set up module dependencies. I have not been able to make this work with eap-6.1, so this request is a backup plan. 
                
> Cannot remove and re-add socket-binding group
> ---------------------------------------------
>
>                 Key: AS7-4468
>                 URL: https://issues.jboss.org/browse/AS7-4468
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>            Reporter: Michael Voegele
>            Assignee: Kabir Khan
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> Error message when trying to (remove and) add a socket-binding-group in domain mode:
> First remove:
> { "operation" => "remove", "address" => [("socket-binding-group" => "standard-sockets")] }
> Result:
> {
> "outcome" : "success",
> "result" : null,
> "server-groups" : {"server-group-1" : {"server-1" : {
> "host" : "master",
> "response" : {"outcome" : "success"}
> }}}
> }
> Now add again:
> {
> "name" : "standard-sockets",
> "default-interface" : "public",
> "operation" : "add",
> "address" : [{ "socket-binding-group" : "standard-sockets" }]
> }
> Result:
> {
> "outcome" : "failed",
> "result" : null,
> "failure-description" : "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" : true,
> "server-groups" : {"server-group-1" : {"server-1" : {
> "host" : "master",
> "response" : { "outcome" : "failed", "failure-description" : "JBAS014749: Operation handler failed: Service jboss.socket-binding-manager is already registered", "rolled-back" : true }
> }}}
> }
> For me, this seems a bit strange. If an error shall be produced, then it should be thrown when removing the socket-binding-group, as there is a server running referencing the socket-binding-group via server-group. But if the socket-binding-group can be removed, it should also be possible to add it again (possibly with new defined socket-bindings in the group, then trigger a restart of the server in order to take the newly configured ports 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 issues at jboss.org  Fri Jan 24 13:46:30 2014
From: issues at jboss.org (Filip Bogyai (JIRA))
Date: Fri, 24 Jan 2014 13:46:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2810) HTTPS undertow listener
 request client certificate despite verify-client=NOT_REQUESTED
In-Reply-To: <JIRA.12530325.1390589136865@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530325.1390589136865@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530325.1390589136865.12167.1390589190183@jira02.app.mwc.hst.phx2.redhat.com>

Filip Bogyai created WFLY-2810:
----------------------------------

             Summary: HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED
                 Key: WFLY-2810
                 URL: https://issues.jboss.org/browse/WFLY-2810
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Filip Bogyai
            Assignee: Stuart Douglas
            Priority: Minor


HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 14:26:46 2014
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Jan 2014 14:26:46 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4468) Cannot remove and re-add
 socket-binding group
In-Reply-To: <JIRA.12463690.1334156865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463690.1334156865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463690.1334156865000.12444.1390591606926@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938707#comment-12938707 ] 

Kabir Khan commented on AS7-4468:
---------------------------------

Closed Jira issues aren't really the place for discussion you should use the forum :-) Anyway,

domain.sh --admin-only will start the domain without starting any servers, however that will not allow you to start servers so it is probably not what you are looking for.

Another option is to set auto-start="false" for each server in host.xml, and then manually start them
                
> Cannot remove and re-add socket-binding group
> ---------------------------------------------
>
>                 Key: AS7-4468
>                 URL: https://issues.jboss.org/browse/AS7-4468
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>            Reporter: Michael Voegele
>            Assignee: Kabir Khan
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> Error message when trying to (remove and) add a socket-binding-group in domain mode:
> First remove:
> { "operation" => "remove", "address" => [("socket-binding-group" => "standard-sockets")] }
> Result:
> {
> "outcome" : "success",
> "result" : null,
> "server-groups" : {"server-group-1" : {"server-1" : {
> "host" : "master",
> "response" : {"outcome" : "success"}
> }}}
> }
> Now add again:
> {
> "name" : "standard-sockets",
> "default-interface" : "public",
> "operation" : "add",
> "address" : [{ "socket-binding-group" : "standard-sockets" }]
> }
> Result:
> {
> "outcome" : "failed",
> "result" : null,
> "failure-description" : "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" : true,
> "server-groups" : {"server-group-1" : {"server-1" : {
> "host" : "master",
> "response" : { "outcome" : "failed", "failure-description" : "JBAS014749: Operation handler failed: Service jboss.socket-binding-manager is already registered", "rolled-back" : true }
> }}}
> }
> For me, this seems a bit strange. If an error shall be produced, then it should be thrown when removing the socket-binding-group, as there is a server running referencing the socket-binding-group via server-group. But if the socket-binding-group can be removed, it should also be possible to add it again (possibly with new defined socket-bindings in the group, then trigger a restart of the server in order to take the newly configured ports 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 issues at jboss.org  Fri Jan 24 14:34:29 2014
From: issues at jboss.org (Ramil Israfilov (JIRA))
Date: Fri, 24 Jan 2014 14:34:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.12524.1390592069397@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938712#comment-12938712 ] 

Ramil Israfilov commented on WFLY-880:
--------------------------------------

we are using jboss eap 6.1.1 and can not move to wildfly yet.

                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 14:42:28 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 14:42:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-785) Release PicketBox
	4.0.20.Final
In-Reply-To: <JIRA.12530329.1390592503555@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530329.1390592503555@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530329.1390592503555.12608.1390592548803@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created SECURITY-785:
---------------------------------------

             Summary: Release PicketBox 4.0.20.Final
                 Key: SECURITY-785
                 URL: https://issues.jboss.org/browse/SECURITY-785
             Project: PicketBox 
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 15:10:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jan 2014 15:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.12665.1390594228619@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938722#comment-12938722 ] 

Brian Stansberry commented on WFLY-880:
---------------------------------------

OK, just so you know there is an issue for this in the EAP issue tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1013392. That's the best place to monitor for any fix in EAP. The code that's involved here is significantly different between WildFly and EAP, so any resolution of the issue in EAP 6 may require a different fix.
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 15:28:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 15:28:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-785) Release PicketBox
	4.0.20.Final
In-Reply-To: <JIRA.12530329.1390592503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530329.1390592503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530329.1390592503000.12680.1390595309140@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed SECURITY-785.
-----------------------------------

    Resolution: Done


PicketBox 4.0.20.Final has been released.
                
> Release PicketBox 4.0.20.Final
> ------------------------------
>
>                 Key: SECURITY-785
>                 URL: https://issues.jboss.org/browse/SECURITY-785
>             Project: PicketBox 
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 15:28:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 15:28:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-776) JBoss AS7 certificate
	principal mapping
In-Reply-To: <JIRA.12527996.1387188288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527996.1387188288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527996.1387188288000.12683.1390595309382@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated SECURITY-776:
------------------------------------

    Fix Version/s: PicketBox_4_1_0.Beta1
                       (was: PicketBox_4_0_20.Final)

    
> JBoss AS7 certificate principal mapping
> ---------------------------------------
>
>                 Key: SECURITY-776
>                 URL: https://issues.jboss.org/browse/SECURITY-776
>             Project: PicketBox 
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_20.Final
>            Reporter: Matija Vizintin
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_1_0.Beta1
>
>         Attachments: picketbox_Support_for_certificate_subject_mapping_in_jboss_AS.patch
>
>
> I was working on a patch for certificate subject mapping in JBoss AS 7.1.4.Final. For this purposes I added one class into picketbox.
> JBoss AS 7.1.4.Final actually uses Picketbox 4.0.15 but I couldn't find it in the affects and fix version so I choose 4.0.20
> There is a .patch attached with the added 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 issues at jboss.org  Fri Jan 24 15:28:29 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 15:28:29 -0500 (EST)
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.12688.1390595309741@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated SECURITY-661:
------------------------------------

    Fix Version/s: PicketBox_4_1_0.Beta1
                       (was: PicketBox_4_0_20.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_1_0.Beta1
>
>
> 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 issues at jboss.org  Fri Jan 24 15:36:28 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 15:36:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2811) Upgrade to PicketBox
	4.0.20.Final
In-Reply-To: <JIRA.12530334.1390595785910@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530334.1390595785910@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530334.1390595785910.12700.1390595788787@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created WFLY-2811:
------------------------------------

             Summary: Upgrade to PicketBox 4.0.20.Final
                 Key: WFLY-2811
                 URL: https://issues.jboss.org/browse/WFLY-2811
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.CR1
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: 8.0.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 issues at jboss.org  Fri Jan 24 16:08:28 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Fri, 24 Jan 2014 16:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2811) Upgrade to PicketBox
	4.0.20.Final
In-Reply-To: <JIRA.12530334.1390595785000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530334.1390595785000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530334.1390595785000.12735.1390597708588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated WFLY-2811:
---------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5772

    
> Upgrade to PicketBox 4.0.20.Final
> ---------------------------------
>
>                 Key: WFLY-2811
>                 URL: https://issues.jboss.org/browse/WFLY-2811
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.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 issues at jboss.org  Fri Jan 24 16:34:30 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 24 Jan 2014 16:34:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-469) Parent Issue for Java EE 7
	Support
In-Reply-To: <JIRA.12485198.1361307312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485198.1361307312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485198.1361307312000.12794.1390599270182@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-469.
------------------------------

    Resolution: Done


Hey hey!  We did it!
                
> Parent Issue for Java EE 7 Support
> ----------------------------------
>
>                 Key: WFLY-469
>                 URL: https://issues.jboss.org/browse/WFLY-469
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> This is the parent issue for tracking tasks related to completing our Java EE 7 support.  Do not close the issue unless Jason has given his blessing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 24 17:16:30 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Fri, 24 Jan 2014 17:16:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2812) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530340.1390601766211@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530340.1390601766211@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530340.1390601766211.12818.1390601790085@jira02.app.mwc.hst.phx2.redhat.com>

Chris Dolphy created WFLY-2812:
----------------------------------

             Summary: DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
                 Key: WFLY-2812
                 URL: https://issues.jboss.org/browse/WFLY-2812
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Server
    Affects Versions: 8.0.0.CR1
            Reporter: Chris Dolphy
            Assignee: Jason Greene




The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
{" and "}

" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 17:20:29 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Fri, 24 Jan 2014 17:20:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2812) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530340.1390601766000.12839.1390602029382@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Dolphy updated WFLY-2812:
-------------------------------

    Attachment: helloworld-mdb.tgz


source for test
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2812
>                 URL: https://issues.jboss.org/browse/WFLY-2812
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Chris Dolphy
>            Assignee: Jason Greene
>         Attachments: helloworld-mdb.tgz
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
> {" and "}
> " have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 17:30:28 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Fri, 24 Jan 2014 17:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2812) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530340.1390601766000.12848.1390602628961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Dolphy updated WFLY-2812:
-------------------------------

    Description: 

The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
{" and "}

" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".


  was:


The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
{" and "}

" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".


    Component/s: EE
                     (was: Server)

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2812
>                 URL: https://issues.jboss.org/browse/WFLY-2812
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Chris Dolphy
>            Assignee: Jason Greene
>         Attachments: helloworld-mdb.tgz
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
> {" and "}
> " have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 17:32:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jan 2014 17:32:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.12852.1390602748677@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved JBMETA-371.
-------------------------------------

    Resolution: Done


Fixed in 8.0.0.Final
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 17:50:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jan 2014 17:50:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2812) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530340.1390601766000.12864.1390603828600@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2812:
--------------------------------------

    Assignee: Brian Stansberry  (was: Jason Greene)

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2812
>                 URL: https://issues.jboss.org/browse/WFLY-2812
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Chris Dolphy
>            Assignee: Brian Stansberry
>         Attachments: helloworld-mdb.tgz
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
> {" and "}
> " have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 17:50:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jan 2014 17:50:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2812) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530340.1390601766000.12867.1390603828761@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2812:
-----------------------------------

    Fix Version/s: 8.0.0.Final

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2812
>                 URL: https://issues.jboss.org/browse/WFLY-2812
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Chris Dolphy
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>         Attachments: helloworld-mdb.tgz
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
> {" and "}
> " have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 24 17:56:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jan 2014 17:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2812) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530340.1390601766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530340.1390601766000.12870.1390604188523@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938749#comment-12938749 ] 

Brian Stansberry commented on WFLY-2812:
----------------------------------------

Requires upgrade to jboss-metadata 8.0.0.Final
                
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2812
>                 URL: https://issues.jboss.org/browse/WFLY-2812
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Chris Dolphy
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>         Attachments: helloworld-mdb.tgz
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "$
> {" and "}
> " have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Sat Jan 25 00:08:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Sat, 25 Jan 2014 00:08:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2224) CLI doesn't exit batch mode
 when failures occur in run-batch
In-Reply-To: <JIRA.12502269.1380977814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502269.1380977814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502269.1380977814000.12917.1390626508584@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2224.
-------------------------------------

    Resolution: Done


A message was added next to the error explaining that the cli remains in the batch editing mode.
                
> CLI doesn't exit batch mode when failures occur in run-batch
> ------------------------------------------------------------
>
>                 Key: WFLY-2224
>                 URL: https://issues.jboss.org/browse/WFLY-2224
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> If you execute a batch that fails, the CLI remains in batch mode.
> [domain at localhost:9990 /] batch
> [domain at localhost:9990 / #] /profile=test:add
> #1 /profile=test:add
> [domain at localhost:9990 / #] :bogus
> #2 /:bogus
> [domain at localhost:9990 / #] run-batch
> JBAS014884: No operation named 'bogus' exists at address []
> [domain at localhost:9990 / #]
> This might be intentional (e.g. to let me fix a typo in my ":bogus" op), but if so, perhaps some output explaining that would be good? And for non-interactive mode staying in the batch seems wrong.
> The same problem occurs in the EAP branch, which is where I first noticed it when investigating another issue. In that case the :bogus command wasn't bogus but was a proper op that failed for legitimate reasons. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 00:10:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Sat, 25 Jan 2014 00:10:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2794) FileSystemPathArgument
 doesn't translate paths in getValue(args, required)
In-Reply-To: <JIRA.12530131.1390412505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530131.1390412505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530131.1390412505000.12919.1390626628503@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2794.
-------------------------------------

    Resolution: Done


Fixed.
                
> FileSystemPathArgument doesn't translate paths in getValue(args, required)
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2794
>                 URL: https://issues.jboss.org/browse/WFLY-2794
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> FileSystemPathArgument uses its OS-specific tab-completer to resolve absolute paths in its getValue(args) method but not in getValue(args, 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 issues at jboss.org  Sat Jan 25 05:06:28 2014
From: issues at jboss.org (Frank Cornelis (JIRA))
Date: Sat, 25 Jan 2014 05:06:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.13209.1390644388709@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938766#comment-12938766 ] 

Frank Cornelis commented on WFLY-2809:
--------------------------------------

Did some more tests, even from within the Servlet itself you cannot do:
{code}
PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
{code}
The only contexts that are available are:
* org.jboss.security.auth.spi.CallbackHandler
* javax.security.auth.Subject.container

This while JACC 1.5 clearly states:
4.6.1.3 HttpServletRequest Policy Context Handler
All Servlet containers must register a PolicyContextHandler whose getContext
method returns a javax.servlet.http.HttpServletRequest object when invoked with
the key ?javax.servlet.http.HttpServletRequest?. When this handler is activated,
the container must return the HttpServletRequest object corresponding to the
component request being processed by the container.
                
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: Stefan Guilhen
>            Priority: Blocker
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Sat Jan 25 05:52:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Sat, 25 Jan 2014 05:52:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2813) fix maven plugin inheritance
	in testsuite
In-Reply-To: <JIRA.12530348.1390647114681@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530348.1390647114681@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530348.1390647114681.13231.1390647148594@jira02.app.mwc.hst.phx2.redhat.com>

Aleksandar Kostadinov created WFLY-2813:
-------------------------------------------

             Summary: fix maven plugin inheritance in testsuite
                 Key: WFLY-2813
                 URL: https://issues.jboss.org/browse/WFLY-2813
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Build System
    Affects Versions: 8.0.0.CR1
            Reporter: Aleksandar Kostadinov
            Assignee: Aleksandar Kostadinov


maven-help-plugin and xml-maven-plugin are not properly inherited in integration testsuite modules. As a result some modules do not produce help.* artifacts in target as well running the test suite with -Dnode0/1 results in many failing tests because server is still starting on 127.0.0.1 as in the vanilla wildfly 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 issues at jboss.org  Sat Jan 25 09:56:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sat, 25 Jan 2014 09:56:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1763) TimeService
In-Reply-To: <JIRA.12528486.1388485586000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528486.1388485586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528486.1388485586000.13254.1390661788777@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1763.
----------------------------

    Resolution: Done

    
> TimeService
> -----------
>
>                 Key: JGRP-1763
>                 URL: https://issues.jboss.org/browse/JGRP-1763
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> New service which provides wall clock time at a coarse (configurable) granularity. 
> Motivation: {{System.currentTimeMillis()}} or {{System.nanoTime()}} is sometimes called frequently, e.g. by {{TCPConnectionMap$TCPConnection.updateLastAccessed()}} or in FD/FD_ALL. This has a cost, especially when a lock is held (system calls while a lock is held cause preemption and the thread losing its time slice).
> However, the 2 examples above don't need the exact time, but an approximation of it is OK.
> GOALS:
> * Provide a time service which returns  the last cached value of {{System.timeCurrentMillis()}}
> * This is a quick and efficient call
> * {{TimeService}} registers a timer task which updates its internal cached value every N milliseconds (configurable), e.g. every 500 ms
> BENEFIT:
> For example, in TCPConnection, the timestamp is updated whenever we send or receive a message from the peer. The timestamp is used to expire and close a connection (if configured), and can be updated 100'000 times a second. If the time service provided the current time in ms every 500ms, then {{System.currentTimeMillis()}} would only be called 2 times during a second instead of 100'000 times !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 11:58:28 2014
From: issues at jboss.org (scott bilyeu (JIRA))
Date: Sat, 25 Jan 2014 11:58:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1784) could not flush the cluster
 for state retrieval
In-Reply-To: <JIRA.12530349.1390668994431@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530349.1390668994431@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530349.1390668994431.13263.1390669108721@jira02.app.mwc.hst.phx2.redhat.com>

scott bilyeu created JGRP-1784:
----------------------------------

             Summary: could not flush the cluster for state retrieval
                 Key: JGRP-1784
                 URL: https://issues.jboss.org/browse/JGRP-1784
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.10
         Environment: production
            Reporter: scott bilyeu
            Assignee: Bela Ban


My production environment cluster was working and then stopped for some reason 

now all I get no matter what I try is
2014-01-25 09:20:06,521 WARN  [org.jgroups.protocols.UDP] (JBoss System Threads(1)-3) failed to join /224.0.0.75:7500 on net3: java.net.SocketException: Unrecognized Windows Sockets error: 0: no Inet4Address associated with interface
2014-01-25 09:20:06,521 WARN  [org.jgroups.protocols.UDP] (JBoss System Threads(1)-3) failed to join /224.0.0.75:7500 on net4: java.net.SocketException: Unrecognized Windows Sockets error: 0: no Inet4Address associated with interface
2014-01-25 09:20:06,521 INFO  [STDOUT] (JBoss System Threads(1)-3) 
---------------------------------------------------------
GMS: address is 10.96.100.142:51826 (cluster=IdmPartition)
---------------------------------------------------------
2014-01-25 09:20:06,662 INFO  [org.jboss.cache.jmx.PlatformMBeanServerRegistration] (main) JBossCache MBeans were successfully registered to the platform mbean server.
2014-01-25 09:20:06,709 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (JBoss System Threads(1)-3) Number of cluster members: 2
2014-01-25 09:20:06,709 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (JBoss System Threads(1)-3) Other members: 1
2014-01-25 09:20:06,756 INFO  [STDOUT] (main) 
---------------------------------------------------------
GMS: address is 10.96.100.142:51826 (cluster=IdmPartition-HAPartitionCache)
---------------------------------------------------------
2014-01-25 09:20:08,771 INFO  [org.jboss.cache.RPCManagerImpl] (main) Received new cluster view: [10.96.100.142:51826|0] [10.96.100.142:51826]
2014-01-25 09:20:08,771 INFO  [org.jboss.cache.RPCManagerImpl] (main) Cache local address is 10.96.100.142:51826
2014-01-25 09:20:08,787 INFO  [org.jboss.cache.RPCManagerImpl] (main) state was retrieved successfully (in 2.03 seconds)
2014-01-25 09:20:08,803 INFO  [org.jboss.cache.factories.ComponentRegistry] (main) JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
2014-01-25 09:20:08,803 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (main) Fetching serviceState (will wait for 30000 milliseconds):
2014-01-25 09:20:25,092 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=HAPartition state=Create
java.lang.IllegalStateException: Node 10.96.100.142:51826 could not flush the cluster for state retrieval
	at org.jgroups.JChannel.getState(JChannel.java:1109)
	at org.jgroups.JChannel.getState(JChannel.java:1034)
	at org.jgroups.JChannel.getState(JChannel.java:978)
	at org.jgroups.JChannel.getState(JChannel.java:932)
	at org.jboss.ha.framework.server.ClusterPartition.fetchState(ClusterPartition.java:616)
	at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:422)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
	at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216)
	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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:662)
2014-01-25 09:20:25,092 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (main) Partition IdmPartition destroyed.
2014-01-25 09:20:25,921 INFO  [org.jboss.invocation.unified.server.UnifiedInvokerHA] (main) Service name is jboss:service=invoker,type=unifiedha
2014-01-25 09:20:51,656 WARN  [org.jgroups.protocols.pbcast.NAKACK] (Incoming-11,10.96.100.142:51826) 10.96.100.142:51826] discarded message from non-member 10.96.100.141:58840, my view is [10.96.100.142:51826|0] [10.96.100.142:51826]
2014-01-25 09:20:51,672 WARN  [org.jgroups.protocols.pbcast.NAKACK] (Incoming-16,10.96.100.142:51826) 10.96.100.142:51826] discarded message from non-member 10.96.100.141:58840, my view is [10.96.100.142:51826|0] [10.96.100.142:51826]
2014-01-25 09:20:51,672 ERROR [org.jgroups.protocols.pbcast.NAKACK] (Incoming-17,10.96.100.142:51826) sender 10.96.100.141:58840 not found in xmit_table
2014-01-25 09:20:51,672 ERROR [org.jgroups.protocols.pbcast.NAKACK] (Incoming-17,10.96.100.142:51826) range is null
2014-01-25 09:20:51,672 INFO  [org.jboss.cache.RPCManagerImpl] (Incoming-17,10.96.100.142:51826) Received new cluster view: MergeView::[10.96.100.141:58840|3] [10.96.100.141:58840, 10.96.100.142:51826], subgroups=[[10.96.100.141:58840|2] [10.96.100.141:58840], [10.96.100.142:51826|0] [10.96.100.142:51826]]
2014-01-25 09:21:04,422 WARN  [org.jboss.annotation.factory.AnnotationCreator] (main) No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
2014-01-25 09:21:04,547 WARN  [org.jboss.annotation.factory.AnnotationCreator] (main) No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 13:30:28 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Sat, 25 Jan 2014 13:30:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2507) InflowFlatTestCase and
 InflowJarTestCase are failing on Windows
In-Reply-To: <JIRA.12525047.1384401396000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525047.1384401396000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525047.1384401396000.13281.1390674628918@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938779#comment-12938779 ] 

Eduardo Martins commented on WFLY-2507:
---------------------------------------

Issue 1) was fixed through another issue, the PR was now updated to just handle the leaks when the RA deployment services fail to start.
                
> InflowFlatTestCase and InflowJarTestCase are failing on Windows
> ---------------------------------------------------------------
>
>                 Key: WFLY-2507
>                 URL: https://issues.jboss.org/browse/WFLY-2507
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>            Reporter: Brian Stansberry
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Final
>
>
> Tests are consisently failing on Windows but not on Linux:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-4393166542338832492&tab=testDetails
> Typically that would indicate a problem that manifests when tests are run in a different order; i.e. one test leaving behind something that impacts another.
> I suspect what's happening here is an RA is getting left behind and these tests are finding the wrong one and making assertions against it.
> Note this in the test is used to find the RA id:
> Set<String> ids = repository.getResourceAdapters();
> {code}
> 		assertNotNull(ids);
> 		System.out.println("////RA" + ids.toString());
> 		String piId = getElementContaining(ids,        "MultipleResourceAdapter");
> {code}
> The test logging shows there are two RAs that would match:
> 03:45:54,709 INFO  [stdout] (pool-1-thread-4) ////RA[org.jboss.as.test.integration.jca.rar.MultipleResourceAdapter#27, org.jboss.as.test.integration.jca.rar.MultipleResourceAdapter#28]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 15:46:28 2014
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 25 Jan 2014 15:46:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2814) GetCallerPrincipalTestCase
 fails with ComparisonFailure: expected:<[$local]stop> but was:<[guest]stop>
In-Reply-To: <JIRA.12530350.1390682738894@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530350.1390682738894@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530350.1390682738894.13292.1390682788755@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2814:
-------------------------------------

             Summary: GetCallerPrincipalTestCase fails with ComparisonFailure: expected:<[$local]stop> but was:<[guest]stop>
                 Key: WFLY-2814
                 URL: https://issues.jboss.org/browse/WFLY-2814
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
    Affects Versions: 8.0.0.Final
         Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_60ea_b03
            Reporter: Frank Langelage
            Assignee: Darran Lofthouse
         Attachments: org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.txt, TEST-org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.xml

Running full testsuite fails always with on test 
GetCallerPrincipalTestCase with ComparisonFailure: expected:<[$local]stop> but was:<[guest]stop>
For more see attached files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 15:46:28 2014
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 25 Jan 2014 15:46:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2814) GetCallerPrincipalTestCase
 fails with ComparisonFailure: expected:<[$local]stop> but was:<[guest]stop>
In-Reply-To: <JIRA.12530350.1390682738000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530350.1390682738000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530350.1390682738000.13294.1390682788880@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2814:
----------------------------------

    Attachment: org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.txt
                TEST-org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.xml

    
> GetCallerPrincipalTestCase fails with ComparisonFailure: expected:<[$local]stop> but was:<[guest]stop>
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2814
>                 URL: https://issues.jboss.org/browse/WFLY-2814
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>    Affects Versions: 8.0.0.Final
>         Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_60ea_b03
>            Reporter: Frank Langelage
>            Assignee: Darran Lofthouse
>         Attachments: org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.txt, TEST-org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.xml
>
>
> Running full testsuite fails always with on test 
> GetCallerPrincipalTestCase with ComparisonFailure: expected:<[$local]stop> but was:<[guest]stop>
> For more see attached files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sat Jan 25 16:20:28 2014
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 25 Jan 2014 16:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2815)
 InflowFlatTestCase/InflowJarTestCase fail with expected:<1> but was:<0>
In-Reply-To: <JIRA.12530351.1390684713216@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530351.1390684713216@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530351.1390684713216.13300.1390684828668@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2815:
-------------------------------------

             Summary: InflowFlatTestCase/InflowJarTestCase fail with expected:<1> but was:<0>
                 Key: WFLY-2815
                 URL: https://issues.jboss.org/browse/WFLY-2815
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA, Test Suite
    Affects Versions: 8.0.0.Final
         Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_60_b03
            Reporter: Frank Langelage
            Assignee: Jesper Pedersen
         Attachments: org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase.txt, org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase.txt, TEST-org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase.xml, TEST-org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase.xml

Running testsuite using latest sources from github gives errors in 
org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase and 
org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase with
expected:<1> but was:<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 issues at jboss.org  Sat Jan 25 16:20:28 2014
From: issues at jboss.org (Frank Langelage (JIRA))
Date: Sat, 25 Jan 2014 16:20:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2815)
 InflowFlatTestCase/InflowJarTestCase fail with expected:<1> but was:<0>
In-Reply-To: <JIRA.12530351.1390684713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530351.1390684713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530351.1390684713000.13302.1390684828735@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2815:
----------------------------------

    Attachment: org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase.txt
                org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase.txt
                TEST-org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase.xml
                TEST-org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase.xml

    
> InflowFlatTestCase/InflowJarTestCase fail with expected:<1> but was:<0>
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2815
>                 URL: https://issues.jboss.org/browse/WFLY-2815
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Final
>         Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_60_b03
>            Reporter: Frank Langelage
>            Assignee: Jesper Pedersen
>         Attachments: org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase.txt, org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase.txt, TEST-org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase.xml, TEST-org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase.xml
>
>
> Running testsuite using latest sources from github gives errors in 
> org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase and 
> org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase with
> expected:<1> but was:<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 issues at jboss.org  Sat Jan 25 21:55:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Jan 2014 21:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2735) read-operation-names casues
 NullPointerException
In-Reply-To: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529095.1389360809000.13317.1390704928909@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938784#comment-12938784 ] 

Brian Stansberry commented on WFLY-2735:
----------------------------------------

The call should fail, but with a proper OperationFailedException that propagates correctly to the client. It did before some changes I made for WFLY-2527 and should again fail now with the linked PR.
                
> read-operation-names casues NullPointerException
> ------------------------------------------------
>
>                 Key: WFLY-2735
>                 URL: https://issues.jboss.org/browse/WFLY-2735
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
>         at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>         at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         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.1.Final.jar:2.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 issues at jboss.org  Sun Jan 26 05:55:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Sun, 26 Jan 2014 05:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1784) could not flush the cluster
 for state retrieval
In-Reply-To: <JIRA.12530349.1390668994000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530349.1390668994000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530349.1390668994000.13332.1390733728746@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938789#comment-12938789 ] 

Bela Ban commented on JGRP-1784:
--------------------------------

Sorry, but I don't support 2.6, see the JGroups wiki for the reasons
                
> could not flush the cluster for state retrieval
> -----------------------------------------------
>
>                 Key: JGRP-1784
>                 URL: https://issues.jboss.org/browse/JGRP-1784
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.10
>         Environment: production
>            Reporter: scott bilyeu
>            Assignee: Bela Ban
>
> My production environment cluster was working and then stopped for some reason 
> now all I get no matter what I try is
> 2014-01-25 09:20:06,521 WARN  [org.jgroups.protocols.UDP] (JBoss System Threads(1)-3) failed to join /224.0.0.75:7500 on net3: java.net.SocketException: Unrecognized Windows Sockets error: 0: no Inet4Address associated with interface
> 2014-01-25 09:20:06,521 WARN  [org.jgroups.protocols.UDP] (JBoss System Threads(1)-3) failed to join /224.0.0.75:7500 on net4: java.net.SocketException: Unrecognized Windows Sockets error: 0: no Inet4Address associated with interface
> 2014-01-25 09:20:06,521 INFO  [STDOUT] (JBoss System Threads(1)-3) 
> ---------------------------------------------------------
> GMS: address is 10.96.100.142:51826 (cluster=IdmPartition)
> ---------------------------------------------------------
> 2014-01-25 09:20:06,662 INFO  [org.jboss.cache.jmx.PlatformMBeanServerRegistration] (main) JBossCache MBeans were successfully registered to the platform mbean server.
> 2014-01-25 09:20:06,709 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (JBoss System Threads(1)-3) Number of cluster members: 2
> 2014-01-25 09:20:06,709 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (JBoss System Threads(1)-3) Other members: 1
> 2014-01-25 09:20:06,756 INFO  [STDOUT] (main) 
> ---------------------------------------------------------
> GMS: address is 10.96.100.142:51826 (cluster=IdmPartition-HAPartitionCache)
> ---------------------------------------------------------
> 2014-01-25 09:20:08,771 INFO  [org.jboss.cache.RPCManagerImpl] (main) Received new cluster view: [10.96.100.142:51826|0] [10.96.100.142:51826]
> 2014-01-25 09:20:08,771 INFO  [org.jboss.cache.RPCManagerImpl] (main) Cache local address is 10.96.100.142:51826
> 2014-01-25 09:20:08,787 INFO  [org.jboss.cache.RPCManagerImpl] (main) state was retrieved successfully (in 2.03 seconds)
> 2014-01-25 09:20:08,803 INFO  [org.jboss.cache.factories.ComponentRegistry] (main) JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
> 2014-01-25 09:20:08,803 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (main) Fetching serviceState (will wait for 30000 milliseconds):
> 2014-01-25 09:20:25,092 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=HAPartition state=Create
> java.lang.IllegalStateException: Node 10.96.100.142:51826 could not flush the cluster for state retrieval
> 	at org.jgroups.JChannel.getState(JChannel.java:1109)
> 	at org.jgroups.JChannel.getState(JChannel.java:1034)
> 	at org.jgroups.JChannel.getState(JChannel.java:978)
> 	at org.jgroups.JChannel.getState(JChannel.java:932)
> 	at org.jboss.ha.framework.server.ClusterPartition.fetchState(ClusterPartition.java:616)
> 	at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:422)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> 	at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216)
> 	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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:221)
> 	at org.jboss.Main$1.run(Main.java:556)
> 	at java.lang.Thread.run(Thread.java:662)
> 2014-01-25 09:20:25,092 INFO  [org.jboss.ha.framework.interfaces.HAPartition.IdmPartition] (main) Partition IdmPartition destroyed.
> 2014-01-25 09:20:25,921 INFO  [org.jboss.invocation.unified.server.UnifiedInvokerHA] (main) Service name is jboss:service=invoker,type=unifiedha
> 2014-01-25 09:20:51,656 WARN  [org.jgroups.protocols.pbcast.NAKACK] (Incoming-11,10.96.100.142:51826) 10.96.100.142:51826] discarded message from non-member 10.96.100.141:58840, my view is [10.96.100.142:51826|0] [10.96.100.142:51826]
> 2014-01-25 09:20:51,672 WARN  [org.jgroups.protocols.pbcast.NAKACK] (Incoming-16,10.96.100.142:51826) 10.96.100.142:51826] discarded message from non-member 10.96.100.141:58840, my view is [10.96.100.142:51826|0] [10.96.100.142:51826]
> 2014-01-25 09:20:51,672 ERROR [org.jgroups.protocols.pbcast.NAKACK] (Incoming-17,10.96.100.142:51826) sender 10.96.100.141:58840 not found in xmit_table
> 2014-01-25 09:20:51,672 ERROR [org.jgroups.protocols.pbcast.NAKACK] (Incoming-17,10.96.100.142:51826) range is null
> 2014-01-25 09:20:51,672 INFO  [org.jboss.cache.RPCManagerImpl] (Incoming-17,10.96.100.142:51826) Received new cluster view: MergeView::[10.96.100.141:58840|3] [10.96.100.141:58840, 10.96.100.142:51826], subgroups=[[10.96.100.141:58840|2] [10.96.100.141:58840], [10.96.100.142:51826|0] [10.96.100.142:51826]]
> 2014-01-25 09:21:04,422 WARN  [org.jboss.annotation.factory.AnnotationCreator] (main) No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
> 2014-01-25 09:21:04,547 WARN  [org.jboss.annotation.factory.AnnotationCreator] (main) No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 09:35:28 2014
From: issues at jboss.org (Christopher Klein (JIRA))
Date: Sun, 26 Jan 2014 09:35:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913493@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913493@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913493.13341.1390746928548@jira02.app.mwc.hst.phx2.redhat.com>

Christopher Klein created WFLY-2816:
---------------------------------------

             Summary: Favour jboss-persistence.xml if present
                 Key: WFLY-2816
                 URL: https://issues.jboss.org/browse/WFLY-2816
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate, Server
            Reporter: Christopher Klein
            Assignee: Scott Marlow


For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 09:37:28 2014
From: issues at jboss.org (Christopher Klein (JIRA))
Date: Sun, 26 Jan 2014 09:37:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.13343.1390747048509@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Klein updated WFLY-2816:
------------------------------------

    Priority: Minor  (was: Major)

    
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 10:05:28 2014
From: issues at jboss.org (Kai P. (JIRA))
Date: Sun, 26 Jan 2014 10:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2817)
 MailSessionDefinitionAnnotationParser throws NullPointerException
In-Reply-To: <JIRA.12530355.1390748671054@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530355.1390748671054@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530355.1390748671054.13347.1390748728547@jira02.app.mwc.hst.phx2.redhat.com>

Kai P. created WFLY-2817:
----------------------------

             Summary: MailSessionDefinitionAnnotationParser throws NullPointerException
                 Key: WFLY-2817
                 URL: https://issues.jboss.org/browse/WFLY-2817
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Mail
    Affects Versions: 8.0.0.CR1
            Reporter: Kai P.
            Assignee: Tomaz Cerar


Having a @MailSessionDefinition annotation with properties, MailSessionDefinitionAnnotationParser throws a NullPointerException

{code}
@MailSessionDefinition(
		name = "java:comp/devMailSession",
		host = "mymailserver",
		transportProtocol = "smtp",
		user = "myuser",
		password = "mypassword",
		from = "my at email.com",
		properties = {
				"mail.debug=true"
		})
{code}

Stacktrace while starting wildfly:
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: java.lang.NullPointerException
	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.getBindingConfiguration(MailSessionDefinitionAnnotationParser.java:143)
	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.processMailSession(MailSessionDefinitionAnnotationParser.java:107)
	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.deploy(MailSessionDefinitionAnnotationParser.java:96)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
	... 5 more
{code}

Related code:
{code}
        MailSessionMetaData metaData = new MailSessionMetaData();
        metaData.setTransportProtocol(asString(annotationInstance, "transportProtocol"));
        metaData.setStoreProtocol(asString(annotationInstance, "storeProtocol"));
        metaData.setHost(asString(annotationInstance, "host"));
        metaData.setUser(asString(annotationInstance, "user"));
        metaData.setPassword(asString(annotationInstance, "password"));
        metaData.setFrom(asString(annotationInstance, "from"));
        metaData.setName(nameValue.asString());
        String jndiName = MailSessionAdd.getJndiName(nameValue.asString());


        for (String fullProp : asArray(annotationInstance, "properties")) {
            PropertyMetaData p = new PropertyMetaData();
            String[] prop = fullProp.split("=", 2);
            p.setName(prop[0]);
            p.setValue(prop[1]);
            metaData.getProperties().add(p); // thrown NPE
        }
{code}

After looking at MailSessionMetaData the properties property is not initialized so getProperties() returns 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 issues at jboss.org  Sun Jan 26 10:11:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sun, 26 Jan 2014 10:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2817)
 MailSessionDefinitionAnnotationParser throws NullPointerException
In-Reply-To: <JIRA.12530355.1390748671000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530355.1390748671000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530355.1390748671000.13350.1390749088757@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2817:
------------------------------

    Priority: Critical  (was: Major)

    
> MailSessionDefinitionAnnotationParser throws NullPointerException
> -----------------------------------------------------------------
>
>                 Key: WFLY-2817
>                 URL: https://issues.jboss.org/browse/WFLY-2817
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Mail
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kai P.
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> Having a @MailSessionDefinition annotation with properties, MailSessionDefinitionAnnotationParser throws a NullPointerException
> {code}
> @MailSessionDefinition(
> 		name = "java:comp/devMailSession",
> 		host = "mymailserver",
> 		transportProtocol = "smtp",
> 		user = "myuser",
> 		password = "mypassword",
> 		from = "my at email.com",
> 		properties = {
> 				"mail.debug=true"
> 		})
> {code}
> Stacktrace while starting wildfly:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.getBindingConfiguration(MailSessionDefinitionAnnotationParser.java:143)
> 	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.processMailSession(MailSessionDefinitionAnnotationParser.java:107)
> 	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.deploy(MailSessionDefinitionAnnotationParser.java:96)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 5 more
> {code}
> Related code:
> {code}
>         MailSessionMetaData metaData = new MailSessionMetaData();
>         metaData.setTransportProtocol(asString(annotationInstance, "transportProtocol"));
>         metaData.setStoreProtocol(asString(annotationInstance, "storeProtocol"));
>         metaData.setHost(asString(annotationInstance, "host"));
>         metaData.setUser(asString(annotationInstance, "user"));
>         metaData.setPassword(asString(annotationInstance, "password"));
>         metaData.setFrom(asString(annotationInstance, "from"));
>         metaData.setName(nameValue.asString());
>         String jndiName = MailSessionAdd.getJndiName(nameValue.asString());
>         for (String fullProp : asArray(annotationInstance, "properties")) {
>             PropertyMetaData p = new PropertyMetaData();
>             String[] prop = fullProp.split("=", 2);
>             p.setName(prop[0]);
>             p.setValue(prop[1]);
>             metaData.getProperties().add(p); // thrown NPE
>         }
> {code}
> After looking at MailSessionMetaData the properties property is not initialized so getProperties() returns 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 issues at jboss.org  Sun Jan 26 10:11:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Sun, 26 Jan 2014 10:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2817)
 MailSessionDefinitionAnnotationParser throws NullPointerException
In-Reply-To: <JIRA.12530355.1390748671000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530355.1390748671000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530355.1390748671000.13354.1390749088864@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2817:
------------------------------

    Fix Version/s: 8.0.0.Final

    
> MailSessionDefinitionAnnotationParser throws NullPointerException
> -----------------------------------------------------------------
>
>                 Key: WFLY-2817
>                 URL: https://issues.jboss.org/browse/WFLY-2817
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Mail
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kai P.
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Having a @MailSessionDefinition annotation with properties, MailSessionDefinitionAnnotationParser throws a NullPointerException
> {code}
> @MailSessionDefinition(
> 		name = "java:comp/devMailSession",
> 		host = "mymailserver",
> 		transportProtocol = "smtp",
> 		user = "myuser",
> 		password = "mypassword",
> 		from = "my at email.com",
> 		properties = {
> 				"mail.debug=true"
> 		})
> {code}
> Stacktrace while starting wildfly:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.getBindingConfiguration(MailSessionDefinitionAnnotationParser.java:143)
> 	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.processMailSession(MailSessionDefinitionAnnotationParser.java:107)
> 	at org.jboss.as.mail.extension.MailSessionDefinitionAnnotationParser.deploy(MailSessionDefinitionAnnotationParser.java:96)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.CR1.jar:8.0.0.CR1]
> 	... 5 more
> {code}
> Related code:
> {code}
>         MailSessionMetaData metaData = new MailSessionMetaData();
>         metaData.setTransportProtocol(asString(annotationInstance, "transportProtocol"));
>         metaData.setStoreProtocol(asString(annotationInstance, "storeProtocol"));
>         metaData.setHost(asString(annotationInstance, "host"));
>         metaData.setUser(asString(annotationInstance, "user"));
>         metaData.setPassword(asString(annotationInstance, "password"));
>         metaData.setFrom(asString(annotationInstance, "from"));
>         metaData.setName(nameValue.asString());
>         String jndiName = MailSessionAdd.getJndiName(nameValue.asString());
>         for (String fullProp : asArray(annotationInstance, "properties")) {
>             PropertyMetaData p = new PropertyMetaData();
>             String[] prop = fullProp.split("=", 2);
>             p.setName(prop[0]);
>             p.setValue(prop[1]);
>             metaData.getProperties().add(p); // thrown NPE
>         }
> {code}
> After looking at MailSessionMetaData the properties property is not initialized so getProperties() returns 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 issues at jboss.org  Sun Jan 26 17:23:28 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 26 Jan 2014 17:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-786) Improve Memory Performance
 when Audit Logging is Off
In-Reply-To: <JIRA.12530360.1390774990442@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530360.1390774990442@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530360.1390774990442.13418.1390775008603@jira02.app.mwc.hst.phx2.redhat.com>

Philippe Marschall created SECURITY-786:
-------------------------------------------

             Summary: Improve Memory Performance when Audit Logging is Off
                 Key: SECURITY-786
                 URL: https://issues.jboss.org/browse/SECURITY-786
             Project: PicketBox 
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Philippe Marschall
            Assignee: Stefan Guilhen


We did some profiling of or JBoss AS instance and noticed that audit logging on JavaEE resources is causing most of our allocations outside [TLAB|http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html#TLAB]s. This was a bit surprising to use since we don't have audit logging on. We tracked them down to {{org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(String, Resource, Exception)}} which unnecessarily does an eager string conversion of every {{org.jboss.security.authorization.Resource}}. This could be done lazily on demand when audit logging is on in {{AuditEvent#toString}}. Since the map is already of type {{Map<String,Object>}} simply removing the call to {{#toString()}} fixes 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 issues at jboss.org  Sun Jan 26 17:35:29 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 26 Jan 2014 17:35:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-786) Improve Memory Performance
 when Audit Logging is Off
In-Reply-To: <JIRA.12530360.1390774990000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530360.1390774990000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530360.1390774990000.13423.1390775729027@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philippe Marschall updated SECURITY-786:
----------------------------------------

    Git Pull Request: https://github.com/picketbox/picketbox-container/pull/2

    
> Improve Memory Performance when Audit Logging is Off
> ----------------------------------------------------
>
>                 Key: SECURITY-786
>                 URL: https://issues.jboss.org/browse/SECURITY-786
>             Project: PicketBox 
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Philippe Marschall
>            Assignee: Stefan Guilhen
>
> We did some profiling of or JBoss AS instance and noticed that audit logging on JavaEE resources is causing most of our allocations outside [TLAB|http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html#TLAB]s. This was a bit surprising to use since we don't have audit logging on. We tracked them down to {{org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(String, Resource, Exception)}} which unnecessarily does an eager string conversion of every {{org.jboss.security.authorization.Resource}}. This could be done lazily on demand when audit logging is on in {{AuditEvent#toString}}. Since the map is already of type {{Map<String,Object>}} simply removing the call to {{#toString()}} fixes 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 issues at jboss.org  Sun Jan 26 17:41:28 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 26 Jan 2014 17:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-787) Speed up SimpleRole#equals
In-Reply-To: <JIRA.12530362.1390776053755@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530362.1390776053755@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530362.1390776053755.13425.1390776088492@jira02.app.mwc.hst.phx2.redhat.com>

Philippe Marschall created SECURITY-787:
-------------------------------------------

             Summary: Speed up SimpleRole#equals
                 Key: SECURITY-787
                 URL: https://issues.jboss.org/browse/SECURITY-787
             Project: PicketBox 
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Philippe Marschall
            Assignee: Stefan Guilhen


We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in `java.lang.Class.cast(Object)`. Switching to a normal Java cast should fix this since we're inside an instanceof and it always succeeds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 17:43:28 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 26 Jan 2014 17:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-787) Speed up SimpleRole#equals
In-Reply-To: <JIRA.12530362.1390776053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530362.1390776053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530362.1390776053000.13429.1390776208588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philippe Marschall updated SECURITY-787:
----------------------------------------

    Description: We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an instanceof and it always succeeds.  (was: We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in `java.lang.Class.cast(Object)`. Switching to a normal Java cast should fix this since we're inside an instanceof and it always succeeds.)

    
> Speed up SimpleRole#equals
> --------------------------
>
>                 Key: SECURITY-787
>                 URL: https://issues.jboss.org/browse/SECURITY-787
>             Project: PicketBox 
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Philippe Marschall
>            Assignee: Stefan Guilhen
>
> We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an instanceof and it always succeeds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 17:43:28 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 26 Jan 2014 17:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-787) Speed up SimpleRole#equals
In-Reply-To: <JIRA.12530362.1390776053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530362.1390776053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530362.1390776053000.13431.1390776208680@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philippe Marschall updated SECURITY-787:
----------------------------------------

    Description: We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an {{instanceof}} and it always succeeds.  (was: We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an instanceof and it always succeeds.)

    
> Speed up SimpleRole#equals
> --------------------------
>
>                 Key: SECURITY-787
>                 URL: https://issues.jboss.org/browse/SECURITY-787
>             Project: PicketBox 
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Philippe Marschall
>            Assignee: Stefan Guilhen
>
> We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an {{instanceof}} and it always succeeds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 17:47:28 2014
From: issues at jboss.org (Philippe Marschall (JIRA))
Date: Sun, 26 Jan 2014 17:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-787) Speed up SimpleRole#equals
In-Reply-To: <JIRA.12530362.1390776053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530362.1390776053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530362.1390776053000.13435.1390776448830@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philippe Marschall updated SECURITY-787:
----------------------------------------

    Git Pull Request: https://github.com/picketbox/picketbox-container/pull/3

    
> Speed up SimpleRole#equals
> --------------------------
>
>                 Key: SECURITY-787
>                 URL: https://issues.jboss.org/browse/SECURITY-787
>             Project: PicketBox 
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Philippe Marschall
>            Assignee: Stefan Guilhen
>
> We did some profiling of our JBoss AS instance and {{SimpleRole#equals(Object)}} showed up as a hot method. A lot of time seems to be spent in {{java.lang.Class.cast(Object)}}. Switching to a normal Java cast should fix this since we're inside an {{instanceof}} and it always succeeds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Sun Jan 26 20:09:28 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Sun, 26 Jan 2014 20:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-416) Queries do not work with
	events
In-Reply-To: <JIRA.12530363.1390784899328@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530363.1390784899328@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530363.1390784899328.13516.1390784968571@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-416:
-------------------------------------

             Summary: Queries do not work with events
                 Key: DROOLS-416
                 URL: https://issues.jboss.org/browse/DROOLS-416
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            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 issues at jboss.org  Mon Jan 27 02:51:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Mon, 27 Jan 2014 02:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.13651.1390809089626@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938830#comment-12938830 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

I upgraded the xnio module on wildfly 8.0.0.Final-SNAPSHOT on friday onto xnio-api/xnio-nio 3.2.0.Beta5-SNAPSHOT but still have the same behaviour.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 02:53:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Mon, 27 Jan 2014 02:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.13655.1390809208564@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938830#comment-12938830 ] 

Matthias Richter edited comment on WFLY-2778 at 1/27/14 2:52 AM:
-----------------------------------------------------------------

I upgraded the xnio module on wildfly 8.0.0.Final-SNAPSHOT on friday onto xnio-api/xnio-nio 3.2.0.Beta5-SNAPSHOT but still have the same behaviour during the weekend. Needed a restart at least every 10 hours, even there was almost no traffic (dev machines).
                
      was (Author: samma):
    I upgraded the xnio module on wildfly 8.0.0.Final-SNAPSHOT on friday onto xnio-api/xnio-nio 3.2.0.Beta5-SNAPSHOT but still have the same behaviour.
                  
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 04:27:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 04:27:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2696) management audit settings:
 syslog protocol is lowercase while uppercase is expected
In-Reply-To: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528489.1388493812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528489.1388493812000.13918.1390814848968@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938868#comment-12938868 ] 

RH Bugzilla Integration commented on WFLY-2696:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1047536|https://bugzilla.redhat.com/show_bug.cgi?id=1047536] from ON_QA to VERIFIED
                
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2696
>                 URL: https://issues.jboss.org/browse/WFLY-2696
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>         Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start  an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> 	at java.lang.Enum.valueOf(Enum.java:214)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 05:31:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 27 Jan 2014 05:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.14047.1390818689022@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938881#comment-12938881 ] 

Tomaz Cerar commented on WFLY-2778:
-----------------------------------

This should be resolved in xnio 3.2.0.Final which is already part of WildFly master.
Can you guys verify that?
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 06:29:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 06:29:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2618) Intermittent 'AssertionError:
 expected:<200> but was:<500>' in
 org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
In-Reply-To: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527235.1386342825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527235.1386342825000.14194.1390822168611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938896#comment-12938896 ] 

RH Bugzilla Integration commented on WFLY-2618:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1049796|https://bugzilla.redhat.com/show_bug.cgi?id=1049796] from ON_QA to ASSIGNED
                
> Intermittent 'AssertionError: expected:<200> but was:<500>' in org.jboss.as.test.manualmode.ws.ReloadWSDLPublisherTestCase.testHelloStringAfterReload
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2618
>                 URL: https://issues.jboss.org/browse/WFLY-2618
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-3843551226685549253&tab=testDetails
> The issue is due to the fact that the jvm is reusing the same connection because it has a keep-alive set to true with a timeout of 5 s.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 06:59:28 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Mon, 27 Jan 2014 06:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-417) Turn on Kie-Ci into an OSGI
	Bundle
In-Reply-To: <JIRA.12530385.1390823961168@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530385.1390823961168@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530385.1390823961168.14238.1390823968567@jira02.app.mwc.hst.phx2.redhat.com>

Charles Moulliard created DROOLS-417:
----------------------------------------

             Summary: Turn on Kie-Ci into an OSGI Bundle
                 Key: DROOLS-417
                 URL: https://issues.jboss.org/browse/DROOLS-417
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
            Reporter: Charles Moulliard
            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 issues at jboss.org  Mon Jan 27 07:03:29 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Mon, 27 Jan 2014 07:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-417) Turn on Kie-Ci into an OSGI
	Bundle
In-Reply-To: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530385.1390823961000.14245.1390824209081@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938905#comment-12938905 ] 

Charles Moulliard commented on DROOLS-417:
------------------------------------------

- Project has been created to generate a bundle of kie-ci maven module
- As there are dependencies issues with maven, aether, sonatype (which are not OSGIfied), the jar of Kie-Ci created will embed theses deps

{code}
ar -vxf kie-ci-6.1.0-SNAPSHOT.jar
x META-INF/MANIFEST.MF
x META-INF/
x META-INF/maven/
x META-INF/maven/org.kie/
x META-INF/maven/org.kie/kie-ci/
x META-INF/maven/org.kie/kie-ci/pom.properties
x META-INF/maven/org.kie/kie-ci/pom.xml
x lib/
x lib/aether-api-1.13.1.jar
x lib/aether-connector-file-1.13.1.jar
x lib/aether-connector-wagon-1.13.1.jar
x lib/aether-impl-1.13.1.jar
x lib/aether-util-1.13.1.jar
x lib/ant-1.8.2.jar
x lib/httpcore-4.2.1.jar
x lib/maven-aether-provider-3.0.5.jar
x lib/maven-compat-3.0.5.jar
x lib/maven-core-3.0.5.jar
x lib/maven-model-3.0.5.jar
x lib/maven-settings-3.0.5.jar
x lib/wagon-http-1.0.jar
{code}
                
> Turn on Kie-Ci into an OSGI Bundle
> ----------------------------------
>
>                 Key: DROOLS-417
>                 URL: https://issues.jboss.org/browse/DROOLS-417
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            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 issues at jboss.org  Mon Jan 27 07:05:29 2014
From: issues at jboss.org (Charles Moulliard (JIRA))
Date: Mon, 27 Jan 2014 07:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-417) Turn on Kie-Ci into an OSGI
	Bundle
In-Reply-To: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530385.1390823961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530385.1390823961000.14251.1390824329706@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938906#comment-12938906 ] 

Charles Moulliard commented on DROOLS-417:
------------------------------------------

ISSUE : The existing project (bundle + embed deps) cannot be generated as maven-source or maven-enforcer does not allow it.

DOES NOT WORK

https://gist.github.com/8647422

WORK

https://gist.github.com/8647417

Ideas are welcome
                
> Turn on Kie-Ci into an OSGI Bundle
> ----------------------------------
>
>                 Key: DROOLS-417
>                 URL: https://issues.jboss.org/browse/DROOLS-417
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            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 issues at jboss.org  Mon Jan 27 07:37:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Mon, 27 Jan 2014 07:37:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2818) LdapRoleMappingG2UTestCase
	fails
In-Reply-To: <JIRA.12530391.1390826128915@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530391.1390826128915@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530391.1390826128915.14332.1390826248617@jira02.app.mwc.hst.phx2.redhat.com>

Aleksandar Kostadinov created WFLY-2818:
-------------------------------------------

             Summary: LdapRoleMappingG2UTestCase fails
                 Key: WFLY-2818
                 URL: https://issues.jboss.org/browse/WFLY-2818
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.CR1
         Environment: all
            Reporter: Aleksandar Kostadinov
            Assignee: Ondrej Zizka


LdapRoleMappingG2UTestCase fails being unable to start wildfly container with arquillian. Actually container is started and I don't see any server errors in the log.

If I try to connect the server with cli before arquillian start timeout expires I am asked for a user/password pair so my guess is that the test case is breaking the standard passwordless auth and arquillian can't auth to server so can't verify it is running 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 issues at jboss.org  Mon Jan 27 07:53:30 2014
From: issues at jboss.org (Ladislav Thon (JIRA))
Date: Mon, 27 Jan 2014 07:53:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2818) LdapRoleMappingG2UTestCase
	fails
In-Reply-To: <JIRA.12530391.1390826128000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530391.1390826128000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530391.1390826128000.14403.1390827210043@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938925#comment-12938925 ] 

Ladislav Thon commented on WFLY-2818:
-------------------------------------

Recently, I've seen it failing too, though it worked just fine when I wrote it. No idea what changed since then.
                
> LdapRoleMappingG2UTestCase fails
> --------------------------------
>
>                 Key: WFLY-2818
>                 URL: https://issues.jboss.org/browse/WFLY-2818
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>         Environment: all
>            Reporter: Aleksandar Kostadinov
>            Assignee: Ondrej Zizka
>
> LdapRoleMappingG2UTestCase fails being unable to start wildfly container with arquillian. Actually container is started and I don't see any server errors in the log.
> If I try to connect the server with cli before arquillian start timeout expires I am asked for a user/password pair so my guess is that the test case is breaking the standard passwordless auth and arquillian can't auth to server so can't verify it is running 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 issues at jboss.org  Mon Jan 27 07:57:31 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Mon, 27 Jan 2014 07:57:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2813) fix maven plugin inheritance
	in testsuite
In-Reply-To: <JIRA.12530348.1390647114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530348.1390647114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530348.1390647114000.14487.1390827451013@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-2813:
----------------------------------------

            Assignee: Paul Gier  (was: Aleksandar Kostadinov)
    Git Pull Request: https://github.com/wildfly/wildfly/pull/5782


I prepared a pull request. I've run WF test suite with changed server IPs and it worked fine.
                
> fix maven plugin inheritance in testsuite
> -----------------------------------------
>
>                 Key: WFLY-2813
>                 URL: https://issues.jboss.org/browse/WFLY-2813
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: 8.0.0.CR1
>            Reporter: Aleksandar Kostadinov
>            Assignee: Paul Gier
>              Labels: integration-test, maven, testsuite, wildfly
>
> maven-help-plugin and xml-maven-plugin are not properly inherited in integration testsuite modules. As a result some modules do not produce help.* artifacts in target as well running the test suite with -Dnode0/1 results in many failing tests because server is still starting on 127.0.0.1 as in the vanilla wildfly 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 issues at jboss.org  Mon Jan 27 08:03:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Mon, 27 Jan 2014 08:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2818) LdapRoleMappingG2UTestCase
	fails
In-Reply-To: <JIRA.12530391.1390826128000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530391.1390826128000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530391.1390826128000.14544.1390827809594@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938936#comment-12938936 ] 

Aleksandar Kostadinov commented on WFLY-2818:
---------------------------------------------

btw it (the rbac module) is not run in upstream CI. It requires -DallTests which seems not used in the wildfly regular CI runs. I'd suggest enabling the rbac module by default.
                
> LdapRoleMappingG2UTestCase fails
> --------------------------------
>
>                 Key: WFLY-2818
>                 URL: https://issues.jboss.org/browse/WFLY-2818
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>         Environment: all
>            Reporter: Aleksandar Kostadinov
>            Assignee: Ondrej Zizka
>
> LdapRoleMappingG2UTestCase fails being unable to start wildfly container with arquillian. Actually container is started and I don't see any server errors in the log.
> If I try to connect the server with cli before arquillian start timeout expires I am asked for a user/password pair so my guess is that the test case is breaking the standard passwordless auth and arquillian can't auth to server so can't verify it is running 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 issues at jboss.org  Mon Jan 27 08:11:29 2014
From: issues at jboss.org (David Ward (JIRA))
Date: Mon, 27 Jan 2014 08:11:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.14572.1390828289868@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938940#comment-12938940 ] 

David Ward commented on DROOLS-364:
-----------------------------------

I do not know about the "exploded ear" scenario, but it appears that whereas DROOLS-340 fixed the "mvn jboss-as:deploy" issue on Macs (my OS), it is still broken on Windows.  Given that this new bug (DROOLS-364) was written based on an error on Windows, it is probable it is the same path error.

Given that, I am attaching a reproducer that might help in debugging this situation.  Again, this is for the "mvn jboss-as:deploy" usecase on Windows, not the "exploded ear" scenario.  However, they are probably the same path error.

Instructions:
1) Download and install a fresh JBoss EAP 6.1.1.
2) Download kie-eap-integration-brms-6.0.1.Final-brms-layer.zip from Nexus and extract it on top of JBoss EAP 6.1.1.
3) Download the attached reproducer from this jira, which is aligned with Drools 6.0.1.Final: jbossas-deploy-reproducer.zip
4) Extract jbossas-deploy-reproducer.zip, and from within it's directory - on WINDOWS - execute "mvn jboss-as:deploy".
5) On Windows, the error should look similar to the attached windows-jboss-as-deploy-server.log.
                
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mark Proctor
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Mon Jan 27 08:13:31 2014
From: issues at jboss.org (David Ward (JIRA))
Date: Mon, 27 Jan 2014 08:13:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.14622.1390828411929@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Ward updated DROOLS-364:
------------------------------

    Attachment: jbossas-deploy-reproducer.zip
                windows-jboss-as-deploy-server.log


Attaching reproducer and server log.
                
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mark Proctor
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Mon Jan 27 08:15:30 2014
From: issues at jboss.org (David Ward (JIRA))
Date: Mon, 27 Jan 2014 08:15:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.14645.1390828530755@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938940#comment-12938940 ] 

David Ward edited comment on DROOLS-364 at 1/27/14 8:14 AM:
------------------------------------------------------------

I do not know about the "exploded ear" scenario, but it appears that whereas DROOLS-340 fixed the "mvn jboss-as:deploy" issue on Macs (my OS), it is still broken on Windows.  Given that this new bug (DROOLS-364) was written based on an error on Windows, it is probable a related path error.

Given that, I am attaching a reproducer that might help in debugging this situation.  Again, this is for the "mvn jboss-as:deploy" usecase on Windows, not the "exploded ear" scenario.  However, they are probably the same sort of path error.

Instructions:
1) Download and install a fresh JBoss EAP 6.1.1.
2) Download kie-eap-integration-brms-6.0.1.Final-brms-layer.zip from Nexus and extract it on top of JBoss EAP 6.1.1.
3) Download the attached reproducer from this jira, which is aligned with Drools 6.0.1.Final: jbossas-deploy-reproducer.zip
4) Extract jbossas-deploy-reproducer.zip, and from within it's directory - on WINDOWS - execute "mvn jboss-as:deploy".
5) On Windows, the error should look similar to the attached windows-jboss-as-deploy-server.log.
                
      was (Author: dward):
    I do not know about the "exploded ear" scenario, but it appears that whereas DROOLS-340 fixed the "mvn jboss-as:deploy" issue on Macs (my OS), it is still broken on Windows.  Given that this new bug (DROOLS-364) was written based on an error on Windows, it is probable it is the same path error.

Given that, I am attaching a reproducer that might help in debugging this situation.  Again, this is for the "mvn jboss-as:deploy" usecase on Windows, not the "exploded ear" scenario.  However, they are probably the same path error.

Instructions:
1) Download and install a fresh JBoss EAP 6.1.1.
2) Download kie-eap-integration-brms-6.0.1.Final-brms-layer.zip from Nexus and extract it on top of JBoss EAP 6.1.1.
3) Download the attached reproducer from this jira, which is aligned with Drools 6.0.1.Final: jbossas-deploy-reproducer.zip
4) Extract jbossas-deploy-reproducer.zip, and from within it's directory - on WINDOWS - execute "mvn jboss-as:deploy".
5) On Windows, the error should look similar to the attached windows-jboss-as-deploy-server.log.
                  
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mark Proctor
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Mon Jan 27 08:19:31 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Mon, 27 Jan 2014 08:19:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1130) vault shared key should be
	salted
In-Reply-To: <JIRA.12471119.1343205463000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471119.1343205463000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471119.1343205463000.14728.1390828771473@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek resolved WFLY-1130.
--------------------------------

    Resolution: Out of Date


This issue is outdated by new implementation of PicketBox Security Vault.
The vault is using symmetric encryption with key stored in keystore and not using shared key any more. 
---
commit 6176d4cf9d4b8cb73a92b01cfb9214292ed18b52
Author: Peter Skopek <pskopek at redhat.com> 2013-08-05 21:24:13
Committer: Brian Stansberry <brian.stansberry at redhat.com> 2013-10-07 22:29:27
                
> vault shared key should be salted
> ---------------------------------
>
>                 Key: WFLY-1130
>                 URL: https://issues.jboss.org/browse/WFLY-1130
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Gernot P
>            Assignee: Peter Skopek
>
> Actual behaviour:
> (1) create a vault entry with
>      vault attribute value: xxx
>      vault block: y1
>      vault attribute name: z1
> (2) create another vault entry with
>      vault attribute value: xxx
>      vault block: y2
>      vault attribute name: z2
> and you see that vault shared key is the same for entry 1 and entry 2
> feature request:
> two vault entries with same attribute value but different block names and attribute names should have different shared keys

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 08:59:28 2014
From: issues at jboss.org (Shaun Appleton (JIRA))
Date: Mon, 27 Jan 2014 08:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-543) Provide an operation to
 request service status report after server has been started
In-Reply-To: <JIRA.12437340.1305215444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437340.1305215444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437340.1305215444000.15023.1390831168637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938963#comment-12938963 ] 

Shaun Appleton commented on WFLY-543:
-------------------------------------

Adding a notification mechanism to this would be beneficial as you can be notified of start and whether there were any errors.
                
> Provide an operation to request  service status report  after server has been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-543
>                 URL: https://issues.jboss.org/browse/WFLY-543
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Heiko Braun
>              Labels: console_prio
>             Fix For: 8.0.0.Final
>
>
> For proper healthcare it would beneficial if I could verify the server status after it has been started. I.e. to catch these, which currently only appear in the server log:
> [Server:server-three] 17:48:26,636 INFO  [org.jboss.as.server] (MSC service thread 1-2) Service status report
> [Server:server-three]    New missing/unsatisfied dependencies:
> [Server:server-three]       service jboss.binding.http2 (missing)
> [Server:server-three] 
> [Server:server-three] 17:48:26,636 ERROR [org.jboss.as] (MSC service thread 1-4) JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" started (with errors) in 3893ms - Started 101 of 149 services (1 services failed or missing dependencies, 47 services are passive or on-demand)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:29:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Jan 2014 09:29:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2795) Escaped expressions are still
 expanded at runtime
In-Reply-To: <JIRA.12530143.1390417554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530143.1390417554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530143.1390417554000.15184.1390832969811@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2795:
-----------------------------------

    Component/s: Domain Management
                     (was: ConfigAdmin)

    
> Escaped expressions are still expanded at runtime
> -------------------------------------------------
>
>                 Key: WFLY-2795
>                 URL: https://issues.jboss.org/browse/WFLY-2795
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> In DMR expressions can be escaped with {{$$}}. Two passes are made in the [ExpressionResolverImpl|https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/ExpressionResolverImpl.java#L119]. The first pass changes {code}$${key}{code} to {code}${key}{code}. The second pass fully expands the expression.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:47:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 09:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1300) org.jboss.log4j.logmanager
 module needs a dependency on javax.mail.api
In-Reply-To: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490786.1367277432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490786.1367277432000.15339.1390834052432@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12938988#comment-12938988 ] 

RH Bugzilla Integration commented on WFLY-1300:
-----------------------------------------------

Jitka Kozana <jkudrnac at redhat.com> changed the Status of [bug 1051335|https://bugzilla.redhat.com/show_bug.cgi?id=1051335] from ON_QA to VERIFIED
                
> org.jboss.log4j.logmanager module needs a dependency on javax.mail.api
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1300
>                 URL: https://issues.jboss.org/browse/WFLY-1300
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Some appenders, like SMTPAppender, require {{javax.mail.api}}. Should probably verify other appenders don't require other modules too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 09:47:32 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 09:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-71) Allow messages to have
 expressions resolved at code generation time
In-Reply-To: <JIRA.12488259.1364483803000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488259.1364483803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488259.1364483803000.15342.1390834052528@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated LOGTOOL-71:
-------------------------------

    Fix Version/s: 1.3.0.Beta1
                       (was: 1.2.0.Final)

    
> Allow messages to have expressions resolved at code generation time
> -------------------------------------------------------------------
>
>                 Key: LOGTOOL-71
>                 URL: https://issues.jboss.org/browse/LOGTOOL-71
>             Project: Log Tool
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 1.3.0.Beta1
>
>
> Allow messages in the {{@Message}} annotation to allow expressions in the format of: 
> {code}
> ${property.name:default}
> {code}
> A warning message should be generated if the property name was not found. If not default is found an error should be generated.
> The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to 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 issues at jboss.org  Mon Jan 27 09:47:32 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 09:47:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-24) Better support for Maven
	logging messages
In-Reply-To: <JIRA.12440146.1308593428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12440146.1308593428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12440146.1308593428000.15345.1390834052660@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGTOOL-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated LOGTOOL-24:
-------------------------------

    Fix Version/s: 1.3.0.Beta1
                       (was: 1.2.0.Final)

    
> Better support for Maven logging messages
> -----------------------------------------
>
>                 Key: LOGTOOL-24
>                 URL: https://issues.jboss.org/browse/LOGTOOL-24
>             Project: Log Tool
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Optional
>             Fix For: 1.3.0.Beta1
>
>
> Maven only prints error and warning messages. Check for ways to print informational and possibly debug messages.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:03:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 10:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2725) Class-Path: . can cause
 JBAS011046: A component named 'TestBean' is already defined in this module
In-Reply-To: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528867.1389194933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528867.1389194933000.15436.1390835009522@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939002#comment-12939002 ] 

RH Bugzilla Integration commented on WFLY-2725:
-----------------------------------------------

Jitka Kozana <jkudrnac at redhat.com> changed the Status of [bug 1050003|https://bugzilla.redhat.com/show_bug.cgi?id=1050003] from ON_QA to VERIFIED
                
> Class-Path: . can cause JBAS011046: A component named 'TestBean' is already defined in this module
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2725
>                 URL: https://issues.jboss.org/browse/WFLY-2725
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Final
>
>
> 'JBAS011046: A component named
> 'TestBean' is already defined in this module', I have narrowed it
> down to it occurs if they have a jar manifest with Class-Path: .
> It looks like when deploying it looks at the jar with the manifest
> entry which then must be having it scan the jar containing the EJB
> again and failing.
> Having the Class-Path: . doesn't really make sense to me, however it
> also seems like we should not be trying to deploy it twice.
> It appears ManifestClassPathProcessor ignores the . when the Class-Path is in a jar at the root of an ear but not when the jar is in a war's WEB-INF/lib
> server/src/main/java/org/jboss/as/server/deployment/module/ManifestClassPathProcessor.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 issues at jboss.org  Mon Jan 27 10:19:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 10:19:29 -0500 (EST)
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.15512.1390835969774@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2047:
------------------------------

    Component/s:     (was: Class Loading)

    
> testConnection should account for deployment classloader
> --------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.CR1
>
>
> 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 issues at jboss.org  Mon Jan 27 10:21:28 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 10:21:28 -0500 (EST)
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.15527.1390836088709@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939013#comment-12939013 ] 

David Lloyd commented on WFLY-2047:
-----------------------------------

https://github.com/wildfly/wildfly/pull/5785 is a PR to revert the revert of the original workaround.  The underlying issue should still be investigated (it's probably just the connector subsystem not setting TCCL right frankly) but the workaround does no harm and allows things to function.
                
> testConnection should account for deployment classloader
> --------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>             Fix For: 9.0.0.CR1
>
>
> 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 issues at jboss.org  Mon Jan 27 10:27:28 2014
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Mon, 27 Jan 2014 10:27:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354667@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354667@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354667.15563.1390836448654@jira02.app.mwc.hst.phx2.redhat.com>

Ryan Emerson created JGRP-1785:
----------------------------------

             Summary: TOA, inconsistent message delivery
                 Key: JGRP-1785
                 URL: https://issues.jboss.org/browse/JGRP-1785
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.5
         Environment: Fedora release 17 (Beefy Miracle)
            Reporter: Ryan Emerson
            Assignee: Bela Ban


When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  

I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:37:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 10:37:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin
 console setup redirects to http address
In-Reply-To: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524948.1384302668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524948.1384302668000.15609.1390837049988@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939021#comment-12939021 ] 

RH Bugzilla Integration commented on WFLY-2498:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1051171|https://bugzilla.redhat.com/show_bug.cgi?id=1051171] from ON_QA to VERIFIED
                
>  Logout of secured (ssl) admin console setup redirects to http address
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2498
>                 URL: https://issues.jboss.org/browse/WFLY-2498
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web Console
>            Reporter: Chris Dolphy
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> Description of problem:
> Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found 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 issues at jboss.org  Mon Jan 27 10:43:28 2014
From: issues at jboss.org (Eric van der Maarel (JIRA))
Date: Mon, 27 Jan 2014 10:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2800) Re-invoking
 InterceptorContext.proceed() throws CannotProceedException
In-Reply-To: <JIRA.12530192.1390476344000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530192.1390476344000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530192.1390476344000.15635.1390837408817@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric van der Maarel updated WFLY-2800:
--------------------------------------

    Summary: Re-invoking InterceptorContext.proceed() throws CannotProceedException  (was: Re-invoking InterceptorContext.proceed() throws CannoteProceedException)

    
> Re-invoking InterceptorContext.proceed() throws CannotProceedException
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2800
>                 URL: https://issues.jboss.org/browse/WFLY-2800
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Eric van der Maarel
>
> When you invoke and re-invoke org.jboss.invocation.InterceptorContext.proceed() from an interceptor in a chain of interceptors and the interceptor to be (re-)invoked is a org.jboss.invocation.ChainedInterceptor or WeavedInterceptor, a CannotProceedException is thrown.
> This bug has been described and analysed in the context of the ejb3 container, on the forum at https://community.jboss.org/message/853547.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:43:29 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 27 Jan 2014 10:43:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.15646.1390837409388@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939025#comment-12939025 ] 

Scott Marlow commented on WFLY-2816:
------------------------------------

You can already include WildFly specific hints or properties that are ignored by WebSphere.  You can also add WebSphere specific properties that are ignored by WildFly (JBoss).

What is the use case that you see this being used?  Is this about doing development on WildFly and deploying in production elsewhere?
                
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:49:30 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Jan 2014 10:49:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.15740.1390837770637@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban reassigned JGRP-1785:
------------------------------

    Assignee: Pedro Ruivo  (was: Bela Ban)


Pedro, can you take a look please ?
                
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:49:31 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Jan 2014 10:49:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.15751.1390837771167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1785:
---------------------------

    Fix Version/s: 3.5

    
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:49:31 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Mon, 27 Jan 2014 10:49:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742829@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742829@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742829.15758.1390837771497@jira02.app.mwc.hst.phx2.redhat.com>

Nedo Nedic created DROOLS-418:
---------------------------------

             Summary: MVEL Unable to resolve method exception on fact update
                 Key: DROOLS-418
                 URL: https://issues.jboss.org/browse/DROOLS-418
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
         Environment: Linux Mint 15
Jboss 5.1
            Reporter: Nedo Nedic
            Assignee: Mark Proctor


The following rule will fail with an exception after update is called on a fact:

	rule "Classifier"
	    no-loop true
	    salience 65430
            when
	          $sn:Snort(sig_priority == "1", type == null)
            then
	          $sn.setType("LOW");
	          update($sn);
            end

[Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
[Near : {... type == "LOW" ....}]
             ^
[Line: 1, Column: 1]
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
        at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
        at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
        at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
        at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
        at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
        at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:53:32 2014
From: issues at jboss.org (Pedro Ruivo (JIRA))
Date: Mon, 27 Jan 2014 10:53:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.15857.1390838012060@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939033#comment-12939033 ] 

Pedro Ruivo commented on JGRP-1785:
-----------------------------------

[~belaban] yes. 
[~ryanemerson] can you attach the jgroups configuration file? 
                
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 10:55:30 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Mon, 27 Jan 2014 10:55:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.15892.1390838130512@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939034#comment-12939034 ] 

Davide Sottara commented on DROOLS-418:
---------------------------------------

Could you please show the Snort class source code as well?
Thanks
Davide
                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:01:30 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 11:01:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2792) Upgrade Java EE 7 Spec APIs
 to .Final versions
In-Reply-To: <JIRA.12530122.1390409593000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530122.1390409593000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530122.1390409593000.15951.1390838490075@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved WFLY-2792.
----------------------------------

    Resolution: Done


Pull request has been merged.
                
> Upgrade Java EE 7 Spec APIs to .Final versions
> ----------------------------------------------
>
>                 Key: WFLY-2792
>                 URL: https://issues.jboss.org/browse/WFLY-2792
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.Final
>
>
> Specifically:
> org.jboss.spec.javax.security.auth.message.jboss-jaspi-api_1.1_spec 1.0.0.Alpha1
> org.jboss.spec.javax.security.jacc.jboss-jacc-api_1.5_spec 1.0.0.Beta1
> org.jboss.spec.javax.el.jboss-el-api_3.0_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jsp.jboss-jsp-api_2.3_spec 1.0.0.Beta1
> org.jboss.spec.javax.servlet.jstl.jboss-jstl-api_1.2_spec 1.0.4.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 issues at jboss.org  Mon Jan 27 11:07:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:07:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2800) Re-invoking
 InterceptorContext.proceed() throws CannotProceedException
In-Reply-To: <JIRA.12530192.1390476344000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530192.1390476344000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530192.1390476344000.15976.1390838849274@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2800:
------------------------------

    Steps to Reproduce: 
Deploy a session bean that requires a transaction and have it throw a org.jboss.util.deadlock.ApplicationDeadlockException.

or

Add the following test case to org.jboss.invocation.test.ChainedInterceptorTestCase and run mvn test on the jboss-invocation subproject.

{code}
    /**
     * What if again re-invokes a chained interceptor?
     */
    @Test
    public void testAgainWithChain() throws Exception {
        Method method = ChainedInterceptorTestCase.class.getMethod("echo", String.class);
        InterceptorContext context = new InterceptorContext();
        context.setMethod(method);
        context.setTarget(this);
        context.setParameters(new Object[] { "testAgain" });

        Interceptor again = new Interceptor() {
            private int num = 2;
            @Override
            public Object processInvocation(InterceptorContext context) throws Exception {
                StringBuilder result = new StringBuilder();
                while ((num--) > 0)
                    result.append(context.proceed());
                return result;
            }       
        };      
        Interceptor interceptor1 = Interceptors.getChainedInterceptor(createMyInterceptor("1"), createMyInterceptor("2"), Interceptors.getInvokingInterceptor());
        Interceptor interceptor2 = Interceptors.getChainedInterceptor(createMyInterceptor("3"), createMyInterceptor("4"), again, interceptor1);

        String result = (String) interceptor2.processInvocation(context);
        String expected = "3#4#1#2#Echo testAgain1#2#Echo testAgain";
        assertEquals(expected, result);
    }       
}
{code}

  was:
Deploy a session bean that requires a transaction and have it throw a org.jboss.util.deadlock.ApplicationDeadlockException.

or

Add the following test case to org.jboss.invocation.test.ChainedInterceptorTestCase and run mvn test on the jboss-invocation subproject.

    /**
     * What if again re-invokes a chained interceptor?
     */
    @Test
    public void testAgainWithChain() throws Exception {
        Method method = ChainedInterceptorTestCase.class.getMethod("echo", String.class);
        InterceptorContext context = new InterceptorContext();
        context.setMethod(method);
        context.setTarget(this);
        context.setParameters(new Object[] { "testAgain" });

        Interceptor again = new Interceptor() {
            private int num = 2;
            @Override
            public Object processInvocation(InterceptorContext context) throws Exception {
                StringBuilder result = new StringBuilder();
                while ((num--) > 0)
                    result.append(context.proceed());
                return result;
            }       
        };      
        Interceptor interceptor1 = Interceptors.getChainedInterceptor(createMyInterceptor("1"), createMyInterceptor("2"), Interceptors.getInvokingInterceptor());
        Interceptor interceptor2 = Interceptors.getChainedInterceptor(createMyInterceptor("3"), createMyInterceptor("4"), again, interceptor1);

        String result = (String) interceptor2.processInvocation(context);
        String expected = "3#4#1#2#Echo testAgain1#2#Echo testAgain";
        assertEquals(expected, result);
    }       
}


    
> Re-invoking InterceptorContext.proceed() throws CannotProceedException
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2800
>                 URL: https://issues.jboss.org/browse/WFLY-2800
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Eric van der Maarel
>
> When you invoke and re-invoke org.jboss.invocation.InterceptorContext.proceed() from an interceptor in a chain of interceptors and the interceptor to be (re-)invoked is a org.jboss.invocation.ChainedInterceptor or WeavedInterceptor, a CannotProceedException is thrown.
> This bug has been described and analysed in the context of the ejb3 container, on the forum at https://community.jboss.org/message/853547.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:25:28 2014
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 27 Jan 2014 11:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2811) Upgrade to PicketBox
	4.0.20.Final
In-Reply-To: <JIRA.12530334.1390595785000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530334.1390595785000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530334.1390595785000.16060.1390839928507@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed WFLY-2811.
--------------------------------

    Resolution: Done

    
> Upgrade to PicketBox 4.0.20.Final
> ---------------------------------
>
>                 Key: WFLY-2811
>                 URL: https://issues.jboss.org/browse/WFLY-2811
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.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 issues at jboss.org  Mon Jan 27 11:45:30 2014
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Jan 2014 11:45:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-377) Provide "destroy-queue" and
 "destroy-topic" operations to CLI
In-Reply-To: <JIRA.12460389.1330512371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460389.1330512371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460389.1330512371000.16112.1390841130643@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939055#comment-12939055 ] 

Jeff Mesnil commented on WFLY-377:
----------------------------------

Now that HORNETQ-1225 is fixed, I think we should close this issue without adding these destroy-queue and destroy-topic operations and instead fix WFLY-1513 so that the jms-topic and jms-queue :remove operations so that they effectively remove all resources associated with the JMS destinations.

[~aloubyansky], I'll let you close the issue as out of date if that's ok with you.
                
> Provide "destroy-queue" and "destroy-topic" operations to CLI
> -------------------------------------------------------------
>
>                 Key: WFLY-377
>                 URL: https://issues.jboss.org/browse/WFLY-377
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI, JMS
>            Reporter: Miroslav Novak
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions.
> They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic.
> The goal is to provide a simple way how to get rid of those objects to administrators. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:49:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-364) message-destination element
 in assembly-descriptor throws exception for EJB 2.1 ejb-jar.xml
In-Reply-To: <JIRA.12486759.1362696863000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486759.1362696863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486759.1362696863000.16169.1390841369057@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved JBMETA-364.
--------------------------------

    Fix Version/s: 8.0.0.Alpha1
       Resolution: Done

    
> message-destination element in assembly-descriptor throws exception for EJB 2.1 ejb-jar.xml
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-364
>                 URL: https://issues.jboss.org/browse/JBMETA-364
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ejb
>    Affects Versions: 7.0.4.Final
>            Reporter: David Stephan
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>
> message-destination is not being parsed for ejb 2.1.
> 14:21:01,507 INFO  [org.jboss.as.server] (host-controller-connection-threads - 11) JBAS015870: Deploy of deployment "xxxx-service-impl.ear" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"xxxx-service-impl.ear\".\"xxxx-service-impl.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"xxxx-service-impl.ear\".\"xxxx-service-impl.jar\".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment \"xxxx-service-impl.jar\" of deployment \"xxxx-service-impl.ear\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014185: Exception while parsing ejb-jar.xml: /content/xxxx-service-impl.ear/xxxx-service-impl.jar/META-INF/ejb-jar.xml
>     Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[142,4] 
> Message: Unexpected element '{http://java.sun.com/xml/ns/j2ee}message-destination' encountered"},"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"xxxx-service-impl.ear\".DEPENDENCIES Missing[JBAS014861: <one or more transitive dependencies>]"]}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:51:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-365) Java EE 7 Related Metadata
In-Reply-To: <JIRA.12490022.1366624730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490022.1366624730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490022.1366624730000.16183.1390841489078@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBMETA-365:
-------------------------------

    Fix Version/s: 8.0.0.Alpha3

    
> Java EE 7 Related Metadata
> --------------------------
>
>                 Key: JBMETA-365
>                 URL: https://issues.jboss.org/browse/JBMETA-365
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: client, common, ear, ejb, web
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Alpha3
>
>
> Provide support for Java EE 7:
> - support new namespaces
> - add new metadata + parsers/mergers for app client, ear, ejb and web
> - add module for permissions.xml with metadata and parsers
> - add unit tests for all the new stuff

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:51:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-366) Update Java EE 7 schemas to
 the final releases
In-Reply-To: <JIRA.12495356.1372445543000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495356.1372445543000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495356.1372445543000.16186.1390841489337@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBMETA-366:
-------------------------------

    Fix Version/s: 8.0.0.Beta2

    
> Update Java EE 7 schemas to the final releases
> ----------------------------------------------
>
>                 Key: JBMETA-366
>                 URL: https://issues.jboss.org/browse/JBMETA-366
>             Project: JBoss Metadata
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: client, common, ear, ejb, rar, web
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta2
>
>
> The final release of the Java EE 7 schemas have changes with respect the ones currently in the Metadata 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 issues at jboss.org  Mon Jan 27 11:53:28 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-368) It is not possible to set a
 timeout method for a SingletonBean with the ejb-jar.xml descriptor
In-Reply-To: <JIRA.12509231.1383243922000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509231.1383243922000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509231.1383243922000.16194.1390841608699@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBMETA-368:
-------------------------------

    Fix Version/s: 8.0.0.Beta3

    
> It is not possible to set a timeout method for a SingletonBean with the ejb-jar.xml descriptor
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-368
>                 URL: https://issues.jboss.org/browse/JBMETA-368
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ejb
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>             Fix For: 8.0.0.Beta3
>
>
> Regarding to the EJB3.1 specification chapter 4.3.8 it is possible to have a timeout method for a SingletonBean. This can be done by annotation but not with the deployment descriptor.
> Also the IllegalStateException contain the wrong message

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:53:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 27 Jan 2014 11:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-377) Provide "destroy-queue" and
 "destroy-topic" operations to CLI
In-Reply-To: <JIRA.12460389.1330512371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460389.1330512371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460389.1330512371000.16198.1390841608861@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-377.
------------------------------------

    Resolution: Out of Date


Thanks, Jeff, that makes this rfe unnecessary.
                
> Provide "destroy-queue" and "destroy-topic" operations to CLI
> -------------------------------------------------------------
>
>                 Key: WFLY-377
>                 URL: https://issues.jboss.org/browse/WFLY-377
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI, JMS
>            Reporter: Miroslav Novak
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions.
> They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic.
> The goal is to provide a simple way how to get rid of those objects to administrators. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:53:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-370) Deployment of a war with 2
 web-fragments both containing ejb-local-refs fails
In-Reply-To: <JIRA.12528756.1389114759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528756.1389114759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528756.1389114759000.16203.1390841609079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved JBMETA-370.
--------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> Deployment of a war with 2 web-fragments both containing ejb-local-refs fails
> -----------------------------------------------------------------------------
>
>                 Key: JBMETA-370
>                 URL: https://issues.jboss.org/browse/JBMETA-370
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>         Environment: Win7, Oracle JDK 1.7.0_45, Wildfly 8.0.0-CR1
>            Reporter: Robert Panzer
>             Fix For: 8.0.0.CR1
>
>
> When trying to deploy a WAR containing two web-fragments both containing ejb-local-refs the deployment fails with this error message:
> 17:54:24,669 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "testear.ear" (runtime-name: "testear.ear")
> 17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "testwar.war")
> 17:54:24,815 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "ejbjar.jar")
> 17:55:55,538 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartExcep
> tion in service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
>         at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
>         at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:294)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         ... 5 more
> Caused by: java.lang.IllegalArgumentException: Null administeredObjects
>         at org.jboss.metadata.javaee.spec.RemoteEnvironmentRefsGroupMetaData.setAdministeredObjects(RemoteEnvironmentRefsGroupMetaData.java:431)
>         at org.jboss.metadata.merge.javaee.spec.RemoteEnvironmentRefsGroupMetaDataMerger.augment(RemoteEnvironmentRefsGroupMetaDataMerger.java:337)
>         at org.jboss.metadata.merge.javaee.spec.EnvironmentRefsGroupMetaDataMerger.augment(EnvironmentRefsGroupMetaDataMerger.java:71)
>         at org.jboss.metadata.merge.web.spec.WebCommonMetaDataMerger.augment(WebCommonMetaDataMerger.java:383)
>         at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:292)
>         ... 6 more
> 17:55:55,621 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "testear.ear")]) - failure descr
> iption: {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"testear.ear\".\"testwar.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"testear.ear\"
> .\"testwar.war\".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment \"testwar.war\" of deployment \"testear.ear\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017318: Conflict occurred processing web fragment in JAR: fragment2.jar
>     Caused by: java.lang.IllegalArgumentException: Null administeredObjects"}}
> 17:55:55,881 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "testear.ear" (runtime-name : "testear.ear")
> 17:55:55,882 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."testear.ear"."testwar.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."testear
> .ear"."testwar.war".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "testwar.war" of deployment "testear.ear"
> There seems to be an error in the class RemoteEnvironmentRefsGroupMetaDataMerger because it calls dest.setAdministeredObjects() during augmentation even if the fragment does not contain administered objects (but entries in the ENC so that the merger is called.)
> I created a test application that shows the problem. You can find it at https://github.com/robertpanzer/webfragmenttest.git
> I can also provide a PR.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:55:29 2014
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Mon, 27 Jan 2014 11:55:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.16207.1390841729848@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939066#comment-12939066 ] 

Ryan Emerson commented on JGRP-1785:
------------------------------------

I have encountered this error problem using several different configuration files, however at the minute I am just using the "toa.xml" file that comes with JGroups.  

{code: title=toa.xml | borderStyle=solid}
<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
         mcast_port="${jgroups.udp.mcast_port:45588}"
         tos="8"
         loopback="true"
         max_bundle_size="64K"
         max_bundle_timeout="30"
         ip_ttl="${jgroups.udp.ip_ttl:8}"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         timer_type="new3"
         timer.min_threads="4"
         timer.max_threads="10"
         timer.keep_alive_time="3000"
         timer.queue_max_size="500"

         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="1"
         oob_thread_pool.max_threads="8"
         oob_thread_pool.keep_alive_time="5000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="discard"/>

    <PING timeout="2000"
            num_initial_members="20"/>
    <MERGE2 max_interval="30000"
            min_interval="10000"/>
    <FD_SOCK/>
    <FD_ALL/>
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK2 xmit_interval="1000"
                    xmit_table_num_rows="100"
                    xmit_table_msgs_per_row="2000"
                    xmit_table_max_compaction_time="30000"
                    max_msg_batch_size="500"
                    use_mcast_xmit="false"
                    discard_delivered_msgs="true"/>
    <UNICAST3 xmit_interval="500"
              xmit_table_num_rows="100"
              xmit_table_msgs_per_row="2000"
              xmit_table_max_compaction_time="60000"
              conn_expiry_timeout="0"
              max_msg_batch_size="500"/>
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="4M"/>
    <pbcast.GMS print_local_addr="true" join_timeout="3000"
                view_bundling="true"/>
    <UFC max_credits="2M"
         min_threshold="0.4"/>
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <FRAG2 frag_size="60K"  />
    <RSVP resend_interval="2000" timeout="10000"/>
    <tom.TOA />
    <pbcast.STATE_TRANSFER />
    <!-- pbcast.FLUSH  /-->
</config>
{code}
                
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:55:30 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 11:55:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.16212.1390841730251@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBMETA-371:
-------------------------------

    Fix Version/s: 8.0.0.Final

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Mon Jan 27 11:55:30 2014
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Mon, 27 Jan 2014 11:55:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.16216.1390841730508@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939066#comment-12939066 ] 

Ryan Emerson edited comment on JGRP-1785 at 1/27/14 11:54 AM:
--------------------------------------------------------------

I have encountered this problem using several different configuration files, however at the minute I am just using the "toa.xml" file that comes with JGroups.  

{code: title=toa.xml | borderStyle=solid}
<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
         mcast_port="${jgroups.udp.mcast_port:45588}"
         tos="8"
         loopback="true"
         max_bundle_size="64K"
         max_bundle_timeout="30"
         ip_ttl="${jgroups.udp.ip_ttl:8}"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         timer_type="new3"
         timer.min_threads="4"
         timer.max_threads="10"
         timer.keep_alive_time="3000"
         timer.queue_max_size="500"

         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="1"
         oob_thread_pool.max_threads="8"
         oob_thread_pool.keep_alive_time="5000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="discard"/>

    <PING timeout="2000"
            num_initial_members="20"/>
    <MERGE2 max_interval="30000"
            min_interval="10000"/>
    <FD_SOCK/>
    <FD_ALL/>
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK2 xmit_interval="1000"
                    xmit_table_num_rows="100"
                    xmit_table_msgs_per_row="2000"
                    xmit_table_max_compaction_time="30000"
                    max_msg_batch_size="500"
                    use_mcast_xmit="false"
                    discard_delivered_msgs="true"/>
    <UNICAST3 xmit_interval="500"
              xmit_table_num_rows="100"
              xmit_table_msgs_per_row="2000"
              xmit_table_max_compaction_time="60000"
              conn_expiry_timeout="0"
              max_msg_batch_size="500"/>
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="4M"/>
    <pbcast.GMS print_local_addr="true" join_timeout="3000"
                view_bundling="true"/>
    <UFC max_credits="2M"
         min_threshold="0.4"/>
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <FRAG2 frag_size="60K"  />
    <RSVP resend_interval="2000" timeout="10000"/>
    <tom.TOA />
    <pbcast.STATE_TRANSFER />
    <!-- pbcast.FLUSH  /-->
</config>
{code}
                
      was (Author: ryanemerson):
    I have encountered this error problem using several different configuration files, however at the minute I am just using the "toa.xml" file that comes with JGroups.  

{code: title=toa.xml | borderStyle=solid}
<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
         mcast_port="${jgroups.udp.mcast_port:45588}"
         tos="8"
         loopback="true"
         max_bundle_size="64K"
         max_bundle_timeout="30"
         ip_ttl="${jgroups.udp.ip_ttl:8}"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         timer_type="new3"
         timer.min_threads="4"
         timer.max_threads="10"
         timer.keep_alive_time="3000"
         timer.queue_max_size="500"

         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="1"
         oob_thread_pool.max_threads="8"
         oob_thread_pool.keep_alive_time="5000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="discard"/>

    <PING timeout="2000"
            num_initial_members="20"/>
    <MERGE2 max_interval="30000"
            min_interval="10000"/>
    <FD_SOCK/>
    <FD_ALL/>
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK2 xmit_interval="1000"
                    xmit_table_num_rows="100"
                    xmit_table_msgs_per_row="2000"
                    xmit_table_max_compaction_time="30000"
                    max_msg_batch_size="500"
                    use_mcast_xmit="false"
                    discard_delivered_msgs="true"/>
    <UNICAST3 xmit_interval="500"
              xmit_table_num_rows="100"
              xmit_table_msgs_per_row="2000"
              xmit_table_max_compaction_time="60000"
              conn_expiry_timeout="0"
              max_msg_batch_size="500"/>
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="4M"/>
    <pbcast.GMS print_local_addr="true" join_timeout="3000"
                view_bundling="true"/>
    <UFC max_credits="2M"
         min_threshold="0.4"/>
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <FRAG2 frag_size="60K"  />
    <RSVP resend_interval="2000" timeout="10000"/>
    <tom.TOA />
    <pbcast.STATE_TRANSFER />
    <!-- pbcast.FLUSH  /-->
</config>
{code}
                  
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 11:55:30 2014
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Mon, 27 Jan 2014 11:55:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1785) TOA,
	inconsistent message delivery
In-Reply-To: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530413.1390836354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530413.1390836354000.16222.1390841730821@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939066#comment-12939066 ] 

Ryan Emerson edited comment on JGRP-1785 at 1/27/14 11:54 AM:
--------------------------------------------------------------

I have encountered this problem using several different configuration files, however at the minute I am using the "toa.xml" file that comes with JGroups.  

{code: title=toa.xml | borderStyle=solid}
<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
         mcast_port="${jgroups.udp.mcast_port:45588}"
         tos="8"
         loopback="true"
         max_bundle_size="64K"
         max_bundle_timeout="30"
         ip_ttl="${jgroups.udp.ip_ttl:8}"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         timer_type="new3"
         timer.min_threads="4"
         timer.max_threads="10"
         timer.keep_alive_time="3000"
         timer.queue_max_size="500"

         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="1"
         oob_thread_pool.max_threads="8"
         oob_thread_pool.keep_alive_time="5000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="discard"/>

    <PING timeout="2000"
            num_initial_members="20"/>
    <MERGE2 max_interval="30000"
            min_interval="10000"/>
    <FD_SOCK/>
    <FD_ALL/>
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK2 xmit_interval="1000"
                    xmit_table_num_rows="100"
                    xmit_table_msgs_per_row="2000"
                    xmit_table_max_compaction_time="30000"
                    max_msg_batch_size="500"
                    use_mcast_xmit="false"
                    discard_delivered_msgs="true"/>
    <UNICAST3 xmit_interval="500"
              xmit_table_num_rows="100"
              xmit_table_msgs_per_row="2000"
              xmit_table_max_compaction_time="60000"
              conn_expiry_timeout="0"
              max_msg_batch_size="500"/>
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="4M"/>
    <pbcast.GMS print_local_addr="true" join_timeout="3000"
                view_bundling="true"/>
    <UFC max_credits="2M"
         min_threshold="0.4"/>
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <FRAG2 frag_size="60K"  />
    <RSVP resend_interval="2000" timeout="10000"/>
    <tom.TOA />
    <pbcast.STATE_TRANSFER />
    <!-- pbcast.FLUSH  /-->
</config>
{code}
                
      was (Author: ryanemerson):
    I have encountered this problem using several different configuration files, however at the minute I am just using the "toa.xml" file that comes with JGroups.  

{code: title=toa.xml | borderStyle=solid}
<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
         mcast_port="${jgroups.udp.mcast_port:45588}"
         tos="8"
         loopback="true"
         max_bundle_size="64K"
         max_bundle_timeout="30"
         ip_ttl="${jgroups.udp.ip_ttl:8}"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         timer_type="new3"
         timer.min_threads="4"
         timer.max_threads="10"
         timer.keep_alive_time="3000"
         timer.queue_max_size="500"

         thread_pool.enabled="true"
         thread_pool.min_threads="2"
         thread_pool.max_threads="8"
         thread_pool.keep_alive_time="5000"
         thread_pool.queue_enabled="true"
         thread_pool.queue_max_size="10000"
         thread_pool.rejection_policy="discard"

         oob_thread_pool.enabled="true"
         oob_thread_pool.min_threads="1"
         oob_thread_pool.max_threads="8"
         oob_thread_pool.keep_alive_time="5000"
         oob_thread_pool.queue_enabled="false"
         oob_thread_pool.queue_max_size="100"
         oob_thread_pool.rejection_policy="discard"/>

    <PING timeout="2000"
            num_initial_members="20"/>
    <MERGE2 max_interval="30000"
            min_interval="10000"/>
    <FD_SOCK/>
    <FD_ALL/>
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK2 xmit_interval="1000"
                    xmit_table_num_rows="100"
                    xmit_table_msgs_per_row="2000"
                    xmit_table_max_compaction_time="30000"
                    max_msg_batch_size="500"
                    use_mcast_xmit="false"
                    discard_delivered_msgs="true"/>
    <UNICAST3 xmit_interval="500"
              xmit_table_num_rows="100"
              xmit_table_msgs_per_row="2000"
              xmit_table_max_compaction_time="60000"
              conn_expiry_timeout="0"
              max_msg_batch_size="500"/>
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="4M"/>
    <pbcast.GMS print_local_addr="true" join_timeout="3000"
                view_bundling="true"/>
    <UFC max_credits="2M"
         min_threshold="0.4"/>
    <MFC max_credits="2M"
         min_threshold="0.4"/>
    <FRAG2 frag_size="60K"  />
    <RSVP resend_interval="2000" timeout="10000"/>
    <tom.TOA />
    <pbcast.STATE_TRANSFER />
    <!-- pbcast.FLUSH  /-->
</config>
{code}
                  
> TOA, inconsistent message delivery
> ----------------------------------
>
>                 Key: JGRP-1785
>                 URL: https://issues.jboss.org/browse/JGRP-1785
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Fedora release 17 (Beefy Miracle)
>            Reporter: Ryan Emerson
>            Assignee: Pedro Ruivo
>             Fix For: 3.5
>
>
> When sending total order messages between two nodes, for a prolonged period of time, an inconsistency is encountered when comparing each node's total order of messages.  
> I believe this issue is related to how sequence numbers are handled in the implementation, not the protocol itself.  I appreciate that TOA is designed for environments where the subset of destinations in the network varies, however I have been unable to reproduce this error when the total number of nodes is > 2.  It is still possible that this inconsistency may occur after a large amount of time when the number of nodes is > 2.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:05:29 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Mon, 27 Jan 2014 12:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.16264.1390842329286@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nedo Nedic updated DROOLS-418:
------------------------------

    Description: 
The following rule will fail with an exception after update is called on a fact:

	rule "Classifier"
	    no-loop true
	    salience 65430
            when
	          $sn:Snort(sig_priority == "1", type == null)
            then
	          $sn.setType("LOW");
	          update($sn);
            end


Snort fact type declaration:

	declare Snort
	    @role( event )
	    @timestamp( event_date )
	    @expires( 1h )
	    dport: String
	    data: String
	    sport: String
	    hostname: String
	    type: String
	    sig_priority: String
	    sensor: String
            id: java.lang.Long
	    sig_class_name: String
	    ip_dst: String
	    sig_name: String
	    event_date: java.util.Date
            ip_src: String
	end
[Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
[Near : {... type == "LOW" ....}]
             ^
[Line: 1, Column: 1]
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
        at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
        at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
        at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
        at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
        at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
        at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)



  was:
The following rule will fail with an exception after update is called on a fact:

	rule "Classifier"
	    no-loop true
	    salience 65430
            when
	          $sn:Snort(sig_priority == "1", type == null)
            then
	          $sn.setType("LOW");
	          update($sn);
            end

[Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
[Near : {... type == "LOW" ....}]
             ^
[Line: 1, Column: 1]
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
        at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
        at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
        at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
        at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
        at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
        at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)




    
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:05:29 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Mon, 27 Jan 2014 12:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.16268.1390842329581@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nedo Nedic updated DROOLS-418:
------------------------------

    Description: 
The following rule will fail with an exception after update is called on a fact:

	rule "Classifier"
	    no-loop true
	    salience 65430
            when
	          $sn:Snort(sig_priority == "1", type == null)
            then
	          $sn.setType("LOW");
	          update($sn);
            end


Snort fact type declaration:

	declare Snort
	    @role( event )
	    @timestamp( event_date )
	    @expires( 1h )
	    dport: String
	    data: String
	    sport: String
	    hostname: String
	    type: String
	    sig_priority: String
	    sensor: String
            id: java.lang.Long
	    sig_class_name: String
	    ip_dst: String
	    sig_name: String
	    event_date: java.util.Date
            ip_src: String
	end

[Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
[Near : {... type == "LOW" ....}]
             ^
[Line: 1, Column: 1]
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
        at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
        at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
        at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
        at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
        at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
        at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)



  was:
The following rule will fail with an exception after update is called on a fact:

	rule "Classifier"
	    no-loop true
	    salience 65430
            when
	          $sn:Snort(sig_priority == "1", type == null)
            then
	          $sn.setType("LOW");
	          update($sn);
            end


Snort fact type declaration:

	declare Snort
	    @role( event )
	    @timestamp( event_date )
	    @expires( 1h )
	    dport: String
	    data: String
	    sport: String
	    hostname: String
	    type: String
	    sig_priority: String
	    sensor: String
            id: java.lang.Long
	    sig_class_name: String
	    ip_dst: String
	    sig_name: String
	    event_date: java.util.Date
            ip_src: String
	end
[Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
[Near : {... type == "LOW" ....}]
             ^
[Line: 1, Column: 1]
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
        at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
        at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
        at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
        at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
        at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
        at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
        at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
        at org.mvel2.MVEL.executeExpression(MVEL.java:930)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
        at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
        at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
        at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
        at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
        at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
        at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)




    
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:23:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Jan 2014 12:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1106) Allow duplication of
 configuration parts via management API
In-Reply-To: <JIRA.12486249.1362468208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486249.1362468208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486249.1362468208000.16297.1390843408980@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1106:
-----------------------------------

    Assignee: Brian Stansberry


As part of another issue I want to implement the equivalent of the subsystem "describe" op for all the core resources.

The "describe" op requires the subsystem to take its current config model and output a list of operations that would reconstruct that state. It's used for launching new servers.

If the core model supported the same semantic, then a list of ops could be requested for any part of the model.

With that in hand, it's a simple matter to take the addresses in the relevant ops and mutate them to point to a different part of the tree. Voila, a set of ops to clone a part of the tree into a different branch.
                
> Allow duplication of configuration parts via management API
> -----------------------------------------------------------
>
>                 Key: WFLY-1106
>                 URL: https://issues.jboss.org/browse/WFLY-1106
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Alex Ont
>            Assignee: Brian Stansberry
>
> Allow the possibility to read part of the configuration via management API, modify it and add it back under a new id, without knowing the specific details of the resource.
> This would allow for example adding a new server group configured exactly as an existing, creating a new resource (datasource, etc.) based on an existing one or even creating a profile based on a given one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:31:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 27 Jan 2014 12:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1478) Enable CORS on the server side
In-Reply-To: <JIRA.12493871.1370725730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493871.1370725730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493871.1370725730000.16331.1390843889050@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1478:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Enable CORS on the server side
> ------------------------------
>
>                 Key: WFLY-1478
>                 URL: https://issues.jboss.org/browse/WFLY-1478
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Darran Lofthouse
>             Fix For: 9.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 issues at jboss.org  Mon Jan 27 12:47:29 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 12:47:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-121) Tracker JIRA for APIs required
 by the Java EE 7 Platform Specification
In-Reply-To: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485867.1362012695000.16357.1390844849038@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939084#comment-12939084 ] 

Shelly McGowan commented on JBEE-121:
-------------------------------------

Java EE 7 API Specs BOM, version 1.0.0.CR1 has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-7.0/1.0.0.CR1/
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-web-7.0/1.0.0.CR1/
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-all-7.0/1.0.0.CR1/

                
> Tracker JIRA for APIs required by the Java EE 7 Platform Specification
> ----------------------------------------------------------------------
>
>                 Key: JBEE-121
>                 URL: https://issues.jboss.org/browse/JBEE-121
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.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 issues at jboss.org  Mon Jan 27 12:51:29 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 12:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-97) See if the jstl dependency on
 xalan can be refactored out
In-Reply-To: <JIRA.12451444.1320700577000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12451444.1320700577000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12451444.1320700577000.16363.1390845089021@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-97:
-------------------------------

    Fix Version/s:     (was: JavaEE 7 Spec APIs 1.0.0.CR1)

    
> See if the jstl dependency on xalan can be refactored out
> ---------------------------------------------------------
>
>                 Key: JBEE-97
>                 URL: https://issues.jboss.org/browse/JBEE-97
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Enhancement
>          Components: jboss-jstl-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.0.Beta1
>            Reporter: Paul Gier
>            Assignee: Jason Greene
>
> The JSTL api has a dependency on the xalan fork which is only available in the JBoss repository.  If this can be refactored out, then the complete set of dependencies will be available in central.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:51:29 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 12:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-118) JSTL uses wrong version of
	xalan
In-Reply-To: <JIRA.12471713.1343932789000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471713.1343932789000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471713.1343932789000.16369.1390845089560@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-118:
-----------------------------------

    Assignee: Shelly McGowan  (was: Paul Gier)

    
> JSTL uses wrong version of xalan
> --------------------------------
>
>                 Key: JBEE-118
>                 URL: https://issues.jboss.org/browse/JBEE-118
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Rafael Benevides
>            Assignee: Shelly McGowan
>
> http://mvnrepository.com/artifact/org.jboss.spec.javax.servlet.jstl/jboss-jstl-api_1.2_spec/1.0.3.Final shows a dependency to xalan:xalan:2.7.1.jbossorg-2 that is not on central repositories.
> It should be 2.7.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 issues at jboss.org  Mon Jan 27 12:51:29 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 12:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-112) jboss-javaee-web Leaking
 Dependency to Nexus
In-Reply-To: <JIRA.12465781.1336368241000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465781.1336368241000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465781.1336368241000.16378.1390845089981@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939085#comment-12939085 ] 

Shelly McGowan commented on JBEE-112:
-------------------------------------

This should be resolved in the EE 7 Specs API BOMS:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-7.0/1.0.0.CR1/
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-web-7.0/1.0.0.CR1/
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-all-7.0/1.0.0.CR1/

                
> jboss-javaee-web Leaking Dependency to Nexus
> --------------------------------------------
>
>                 Key: JBEE-112
>                 URL: https://issues.jboss.org/browse/JBEE-112
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Andrew Rubinger
>            Assignee: Shelly McGowan
>
> org.jboss.spec:jboss-javaee-web-6.0 (which is propagated to Maven Central) is leaking a dependency to xalan:xalan:2.7.1.jbossorg-2, which is not present in Maven Central.
> {code}[DEBUG] org.ocpsoft.rewrite:rewrite-parent:pom:1.0.6-SNAPSHOT
> [DEBUG]    org.jboss.spec:jboss-javaee-web-6.0:pom:3.0.1.Final:test
> [DEBUG]          xalan:xalan:jar:2.7.1.jbossorg-2:test{code}
> Either fix to the correct dependency (something in Central) or push the dependent artifact to Central 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 issues at jboss.org  Mon Jan 27 12:51:29 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 12:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-112) jboss-javaee-web Leaking
 Dependency to Nexus
In-Reply-To: <JIRA.12465781.1336368241000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465781.1336368241000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465781.1336368241000.16376.1390845089883@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-112:
-----------------------------------

    Assignee: Shelly McGowan  (was: Paul Gier)

    
> jboss-javaee-web Leaking Dependency to Nexus
> --------------------------------------------
>
>                 Key: JBEE-112
>                 URL: https://issues.jboss.org/browse/JBEE-112
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Andrew Rubinger
>            Assignee: Shelly McGowan
>
> org.jboss.spec:jboss-javaee-web-6.0 (which is propagated to Maven Central) is leaking a dependency to xalan:xalan:2.7.1.jbossorg-2, which is not present in Maven Central.
> {code}[DEBUG] org.ocpsoft.rewrite:rewrite-parent:pom:1.0.6-SNAPSHOT
> [DEBUG]    org.jboss.spec:jboss-javaee-web-6.0:pom:3.0.1.Final:test
> [DEBUG]          xalan:xalan:jar:2.7.1.jbossorg-2:test{code}
> Either fix to the correct dependency (something in Central) or push the dependent artifact to Central 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 issues at jboss.org  Mon Jan 27 12:53:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 12:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-105) Create a JBoss version of the
 JavaBeans activation framework (javax.activation) API
In-Reply-To: <JIRA.12458289.1328289083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458289.1328289083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458289.1328289083000.16386.1390845208589@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-105:
--------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Final
                       (was: JavaEE 7 Spec APIs 1.0.0.CR1)

    
> Create a JBoss version of the JavaBeans activation framework (javax.activation) API
> -----------------------------------------------------------------------------------
>
>                 Key: JBEE-105
>                 URL: https://issues.jboss.org/browse/JBEE-105
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Feature Request
>          Components: general
>            Reporter: Paul Gier
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Final
>
>
> The JBoss jaxr-api jar current depends on the javax.activation 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 issues at jboss.org  Mon Jan 27 12:53:28 2014
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Mon, 27 Jan 2014 12:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2819) Cherry-pick Mojarra fix for
 ClassPathException when custom VisitContextFactory is used
In-Reply-To: <JIRA.12530431.1390845136165@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530431.1390845136165@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530431.1390845136165.16387.1390845208617@jira02.app.mwc.hst.phx2.redhat.com>

Luk?? Fry? created WFLY-2819:
--------------------------------

             Summary: Cherry-pick Mojarra fix for ClassPathException when custom VisitContextFactory is used
                 Key: WFLY-2819
                 URL: https://issues.jboss.org/browse/WFLY-2819
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: 8.0.0.Final
            Reporter: Luk?? Fry?
            Assignee: Stan Silvert


See https://java.net/jira/browse/JAVASERVERFACES-3156

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 12:55:28 2014
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Mon, 27 Jan 2014 12:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2819) Cherry-pick Mojarra fix for
 ClassPathException when custom VisitContextFactory is used
In-Reply-To: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530431.1390845136000.16392.1390845328778@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luk?? Fry? updated WFLY-2819:
-----------------------------

    Description: 
See https://java.net/jira/browse/JAVASERVERFACES-3156

This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.

  was:See https://java.net/jira/browse/JAVASERVERFACES-3156


    
> Cherry-pick Mojarra fix for ClassPathException when custom VisitContextFactory is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2819
>                 URL: https://issues.jboss.org/browse/WFLY-2819
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Luk?? Fry?
>            Assignee: Stan Silvert
>
> See https://java.net/jira/browse/JAVASERVERFACES-3156
> This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 12:55:28 2014
From: issues at jboss.org (Christopher Klein (JIRA))
Date: Mon, 27 Jan 2014 12:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.16396.1390845328977@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939086#comment-12939086 ] 

Christopher Klein commented on WFLY-2816:
-----------------------------------------

As you already guessed it, yes it is about developing on WildFly and deploying in production to WebSphere.

The <non-jta-data-source> content and some properties (<properties><property name="<property name="hibernate.transaction.manager_lookup_class" value="..." /></properties>) differs between both environments. Creating two more or less same EAR artifacts with different persistence.xml content seems to be a little bit messy and I am trying to avoid it.

The hints you mentioned: Can you please give me an example or a link? I looked upon the WildFly documentation but I didn't get it.

                
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:55:29 2014
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Mon, 27 Jan 2014 12:55:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2819) Cherry-pick Mojarra fix for
 ClassPathException when custom VisitContextFactory is used
In-Reply-To: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530431.1390845136000.16402.1390845329277@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luk?? Fry? updated WFLY-2819:
-----------------------------

    Description: 
See https://java.net/jira/browse/JAVASERVERFACES-3156

This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.

See also related update: WFLY-2796

  was:
See https://java.net/jira/browse/JAVASERVERFACES-3156

This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.


    
> Cherry-pick Mojarra fix for ClassPathException when custom VisitContextFactory is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2819
>                 URL: https://issues.jboss.org/browse/WFLY-2819
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Luk?? Fry?
>            Assignee: Stan Silvert
>
> See https://java.net/jira/browse/JAVASERVERFACES-3156
> This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.
> See also related update: WFLY-2796

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 12:55:29 2014
From: issues at jboss.org (Christopher Klein (JIRA))
Date: Mon, 27 Jan 2014 12:55:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.16399.1390845329152@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939086#comment-12939086 ] 

Christopher Klein edited comment on WFLY-2816 at 1/27/14 12:55 PM:
-------------------------------------------------------------------

As you already guessed it, yes it is about developing on WildFly and deploying in production to WebSphere.

The <non-jta-data-source> content and some properties (<properties><property name="hibernate.transaction.manager_lookup_class" value="..." /></properties>) differs between both environments. Creating two more or less same EAR artifacts with different persistence.xml content seems to be a little bit messy and I am trying to avoid it.

The hints you mentioned: Can you please give me an example or a link? I looked upon the WildFly documentation but I didn't get it.

                
      was (Author: schakko):
    As you already guessed it, yes it is about developing on WildFly and deploying in production to WebSphere.

The <non-jta-data-source> content and some properties (<properties><property name="<property name="hibernate.transaction.manager_lookup_class" value="..." /></properties>) differs between both environments. Creating two more or less same EAR artifacts with different persistence.xml content seems to be a little bit messy and I am trying to avoid it.

The hints you mentioned: Can you please give me an example or a link? I looked upon the WildFly documentation but I didn't get it.

                  
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 12:59:28 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 27 Jan 2014 12:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2819) Cherry-pick Mojarra fix for
 ClassPathException when custom VisitContextFactory is used
In-Reply-To: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530431.1390845136000.16411.1390845568706@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma reassigned WFLY-2819:
--------------------------------

    Assignee: Farah Juma  (was: Stan Silvert)

    
> Cherry-pick Mojarra fix for ClassPathException when custom VisitContextFactory is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2819
>                 URL: https://issues.jboss.org/browse/WFLY-2819
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Final
>            Reporter: Luk?? Fry?
>            Assignee: Farah Juma
>
> See https://java.net/jira/browse/JAVASERVERFACES-3156
> This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.
> See also related update: WFLY-2796

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Mon Jan 27 13:15:30 2014
From: issues at jboss.org (Ralf Battenfeld (JIRA))
Date: Mon, 27 Jan 2014 13:15:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2820) Support for Properties File
 in wildfly-arquillian-container-managed
In-Reply-To: <JIRA.12530434.1390846486926@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530434.1390846486926@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530434.1390846486926.16417.1390846530628@jira02.app.mwc.hst.phx2.redhat.com>

Ralf Battenfeld created WFLY-2820:
-------------------------------------

             Summary: Support for Properties File in wildfly-arquillian-container-managed
                 Key: WFLY-2820
                 URL: https://issues.jboss.org/browse/WFLY-2820
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.CR1
            Reporter: Ralf Battenfeld
            Assignee: Ondrej Zizka
             Fix For: 8.0.0.Final


Wildfly supports properties files set as a program argument. For managed arquillian test, this option is currently not supported in the arquillian.xml. If your app is using system properties, then arquillian can not be used as the manager of a wildfly instance.

I originally asked for this feature, and we need it:-)

I will send a PR soon that allows to set 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 issues at jboss.org  Mon Jan 27 13:45:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Jan 2014 13:45:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2821) Intermittent failures in EE
 resource injection tests
In-Reply-To: <JIRA.12530438.1390848308704@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530438.1390848308704@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530438.1390848308704.16450.1390848328738@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2821:
--------------------------------------

             Summary: Intermittent failures in EE resource injection tests
                 Key: WFLY-2821
                 URL: https://issues.jboss.org/browse/WFLY-2821
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
    Affects Versions: 8.0.0.CR1
            Reporter: Brian Stansberry
            Assignee: David Lloyd
             Fix For: 8.0.0.Final


The set of 5 failures shown below are recurring intermittently in the WF testsuite:

http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=8698&buildTypeId=WF_MasterIgnoreWindows&tab=buildResultsDiv

org.jboss.as.test.integration.ee.injection.resource.enventry

 EnvEntryInjectionTestCase.testNonExistantResourceCannotBeLookedUp	
 org.jboss.as.test.integration.ee.injection.resource.noncomponent

 NonComponentResourceInjectionTestCase.testBindingDoesNotExist	

 org.jboss.as.test.integration.ee.injection.resource.persistencecontextref

 PersistenceContextRefTestCase.testCorrectPersistenceUnitInjectedFromAnnotation2	
 PersistenceContextRefTestCase.testCorrectPersistenceUnitInjectedFromPersistenceUnitRef	
 PersistenceContextRefTestCase.testCorrectPersistenceUnitInjectedFromRefInjectionTarget2	


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 13:53:28 2014
From: issues at jboss.org (Ralf Battenfeld (JIRA))
Date: Mon, 27 Jan 2014 13:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2820) Support for Properties File
 in wildfly-arquillian-container-managed
In-Reply-To: <JIRA.12530434.1390846486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530434.1390846486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530434.1390846486000.16459.1390848808606@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Battenfeld updated WFLY-2820:
----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5787

    
> Support for Properties File in wildfly-arquillian-container-managed
> -------------------------------------------------------------------
>
>                 Key: WFLY-2820
>                 URL: https://issues.jboss.org/browse/WFLY-2820
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ralf Battenfeld
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> Wildfly supports properties files set as a program argument. For managed arquillian test, this option is currently not supported in the arquillian.xml. If your app is using system properties, then arquillian can not be used as the manager of a wildfly instance.
> I originally asked for this feature, and we need it:-)
> I will send a PR soon that allows to set 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 issues at jboss.org  Mon Jan 27 13:53:28 2014
From: issues at jboss.org (Ralf Battenfeld (JIRA))
Date: Mon, 27 Jan 2014 13:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2820) Support for Properties File
 in wildfly-arquillian-container-managed
In-Reply-To: <JIRA.12530434.1390846486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530434.1390846486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530434.1390846486000.16461.1390848808723@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939098#comment-12939098 ] 

Ralf Battenfeld commented on WFLY-2820:
---------------------------------------

PR sent for this: https://github.com/wildfly/wildfly/pull/5787

                
> Support for Properties File in wildfly-arquillian-container-managed
> -------------------------------------------------------------------
>
>                 Key: WFLY-2820
>                 URL: https://issues.jboss.org/browse/WFLY-2820
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ralf Battenfeld
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> Wildfly supports properties files set as a program argument. For managed arquillian test, this option is currently not supported in the arquillian.xml. If your app is using system properties, then arquillian can not be used as the manager of a wildfly instance.
> I originally asked for this feature, and we need it:-)
> I will send a PR soon that allows to set 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 issues at jboss.org  Mon Jan 27 14:03:29 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 27 Jan 2014 14:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.16472.1390849409279@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939103#comment-12939103 ] 

Scott Marlow commented on WFLY-2816:
------------------------------------

Thanks, I wanted to better understand the use case.  You shouldn't have to set hibernate.transaction.manager_lookup_class on WildFly but assume you are on WebSphere.

[Open this link to see some hints|https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties] in the documentation.
                
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 14:29:28 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Mon, 27 Jan 2014 14:29:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.16489.1390850968806@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939107#comment-12939107 ] 

Davide Sottara commented on DROOLS-418:
---------------------------------------

I tried it with 5.6.0.Final and I could not reproduce it. Later versions of Drools use later versions of MVEL, so that may be solved.

                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 14:53:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Mon, 27 Jan 2014 14:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.16543.1390852408944@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939110#comment-12939110 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Tomaz,

I installed the latest master of wildfly and the log shows xnio 3.2.0.Final. Tomorrow I should see if that works. Thanks.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 15:41:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 15:41:29 -0500 (EST)
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.16594.1390855289968@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939117#comment-12939117 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

dereed at redhat.com changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from CLOSED to ASSIGNED
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    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 issues at jboss.org  Mon Jan 27 16:19:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 27 Jan 2014 16:19:28 -0500 (EST)
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.16614.1390857568942@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1701:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=984855, https://bugzilla.redhat.com/show_bug.cgi?id=1058481  (was: https://bugzilla.redhat.com/show_bug.cgi?id=984855)

    
> 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
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.1, MS Windows server 
>            Reporter: Tom Ross
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Mon Jan 27 16:25:29 2014
From: issues at jboss.org (Christopher Klein (JIRA))
Date: Mon, 27 Jan 2014 16:25:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.16636.1390857929529@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939126#comment-12939126 ] 

Christopher Klein commented on WFLY-2816:
-----------------------------------------

Ah, thanks for the passage. Had overlooked it respectively searched for other terms.
Would you accept a pull request from me for this feature request or is it something you don't want to include? 
                
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 16:59:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Mon, 27 Jan 2014 16:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.16707.1390859968798@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939133#comment-12939133 ] 

Scott Marlow commented on WFLY-2816:
------------------------------------

I'm not personally seeing the appeal for WildFly but do see the advantage for your use case.  A better place to discuss whether there is interest in this use case would be [https://lists.jboss.org/mailman/listinfo/wildfly-dev].
                
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 17:15:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jan 2014 17:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.16718.1390860929918@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939135#comment-12939135 ] 

David Lloyd commented on WFLY-880:
----------------------------------

I think this should be closed/fixed as of whenever we updated MSC to 1.1.
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 18:21:28 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Mon, 27 Jan 2014 18:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2822) Create a new module to
 provide Hibernate Search functionality to Hibernate users
In-Reply-To: <JIRA.12530445.1390864817781@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530445.1390864817781@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530445.1390864817781.16759.1390864888818@jira02.app.mwc.hst.phx2.redhat.com>

Sanne Grinovero created WFLY-2822:
-------------------------------------

             Summary: Create a new module to provide Hibernate Search functionality to Hibernate users
                 Key: WFLY-2822
                 URL: https://issues.jboss.org/browse/WFLY-2822
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
            Reporter: Sanne Grinovero
            Assignee: Sanne Grinovero
             Fix For: 8.0.0.Final


Since most dependencies are included already, I just need to add the {{hibernate-search-orm.jar}} in a new module and make sure deployed applications can use 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 issues at jboss.org  Mon Jan 27 20:19:28 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 20:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-114) JSF-API from 2.0.1.Final
 introduces inclusion of JSF-IMPL resources
In-Reply-To: <JIRA.12467049.1337694293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467049.1337694293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467049.1337694293000.16823.1390871968716@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939150#comment-12939150 ] 

Shelly McGowan commented on JBEE-114:
-------------------------------------

[~manaRH] is this still something that needs to be addressed in the upstream JSF API Specs project?
                
> JSF-API from 2.0.1.Final introduces inclusion of JSF-IMPL resources
> -------------------------------------------------------------------
>
>                 Key: JBEE-114
>                 URL: https://issues.jboss.org/browse/JBEE-114
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>            Reporter: Marek Novotny
>            Assignee: Paul Gier
>
> org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.0.1.Final and 2.0.2.Final introduces some resources which gather to jsf-impl artifact. That affect some classpath usage when there should be only API classes.
> Concrete example are /META-INF/resources/javax.faces/* files

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Mon Jan 27 20:19:29 2014
From: issues at jboss.org (Shelly McGowan (JIRA))
Date: Mon, 27 Jan 2014 20:19:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-114) JSF-API from 2.0.1.Final
 introduces inclusion of JSF-IMPL resources
In-Reply-To: <JIRA.12467049.1337694293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467049.1337694293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467049.1337694293000.16830.1390871969020@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-114:
-----------------------------------

    Assignee: Farah Juma  (was: Paul Gier)


Reassigning to Farah.
                
> JSF-API from 2.0.1.Final introduces inclusion of JSF-IMPL resources
> -------------------------------------------------------------------
>
>                 Key: JBEE-114
>                 URL: https://issues.jboss.org/browse/JBEE-114
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>            Reporter: Marek Novotny
>            Assignee: Farah Juma
>
> org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.0.1.Final and 2.0.2.Final introduces some resources which gather to jsf-impl artifact. That affect some classpath usage when there should be only API classes.
> Concrete example are /META-INF/resources/javax.faces/* files

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 03:09:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 28 Jan 2014 03:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.17040.1390896568922@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939179#comment-12939179 ] 

RH Bugzilla Integration commented on WFLY-2782:
-----------------------------------------------

Vaclav Tunka <vtunka at redhat.com> changed the Status of [bug 1055912|https://bugzilla.redhat.com/show_bug.cgi?id=1055912] from MODIFIED to ON_QA
                
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 03:41:30 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Tue, 28 Jan 2014 03:41:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.17109.1390898490467@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939191#comment-12939191 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

So with yesterdays master build wildfly final I still have that error. Besides the cpu load I figured out that memory usage of those processes goes up as well.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 03:53:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jan 2014 03:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2761) Make it possible for static
 cdi-enabled modules to see the beans in top-level deployments
In-Reply-To: <JIRA.12529575.1389867009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529575.1389867009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529575.1389867009000.17133.1390899209009@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2761:
----------------------------------

    Priority: Blocker  (was: Critical)


Raising priority to blocker as this is critical for PicketLink integration. Furthermore, the fix is ready just pending review.
                
> Make it possible for static cdi-enabled modules to see the beans in top-level deployments
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2761
>                 URL: https://issues.jboss.org/browse/WFLY-2761
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.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 issues at jboss.org  Tue Jan 28 03:53:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jan 2014 03:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.17141.1390899209500@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2762:
----------------------------------

    Priority: Blocker  (was: Major)


Raising priority to blocker as this is critical for Bean Validation integration. Furthermore, the fix is ready just pending review.
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 03:53:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jan 2014 03:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.17149.1390899209990@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2762:
----------------------------------

    Fix Version/s: 8.0.0.Final

    
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 03:53:30 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Tue, 28 Jan 2014 03:53:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.17153.1390899210214@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nedo Nedic updated DROOLS-418:
------------------------------

    Attachment: Classifier.xls


Decision table
                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 03:57:28 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Tue, 28 Jan 2014 03:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.17172.1390899448705@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939198#comment-12939198 ] 

Nedo Nedic edited comment on DROOLS-418 at 1/28/14 3:55 AM:
------------------------------------------------------------

The rule is built from a decision table (if that can change the unit test). I have attached it. I'm using mvel2-2.1.8.Final.jar
                
      was (Author: nedoo):
    Decision table
                  
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 04:27:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Tue, 28 Jan 2014 04:27:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2813) fix maven plugin inheritance
	in testsuite
In-Reply-To: <JIRA.12530348.1390647114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530348.1390647114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530348.1390647114000.17220.1390901249692@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov closed WFLY-2813.
---------------------------------------

         Assignee: Aleksandar Kostadinov  (was: Paul Gier)
    Fix Version/s: 8.0.0.Final
       Resolution: Done


PR was merged
                
> fix maven plugin inheritance in testsuite
> -----------------------------------------
>
>                 Key: WFLY-2813
>                 URL: https://issues.jboss.org/browse/WFLY-2813
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: 8.0.0.CR1
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: integration-test, maven, testsuite, wildfly
>             Fix For: 8.0.0.Final
>
>
> maven-help-plugin and xml-maven-plugin are not properly inherited in integration testsuite modules. As a result some modules do not produce help.* artifacts in target as well running the test suite with -Dnode0/1 results in many failing tests because server is still starting on 127.0.0.1 as in the vanilla wildfly 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 issues at jboss.org  Tue Jan 28 04:33:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 04:33:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.17256.1390901608816@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939211#comment-12939211 ] 

Tomaz Cerar commented on WFLY-2778:
-----------------------------------

Can post new thread dump that you get when cpu is at 99%?
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 04:47:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Jan 2014 04:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1764)
 TCPConnectionMap$TCPConnection: update time stamp only if connection
 reaping is enabled
In-Reply-To: <JIRA.12528487.1388486185000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528487.1388486185000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528487.1388486185000.17281.1390902448703@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1764.
----------------------------

    Resolution: Done

    
> TCPConnectionMap$TCPConnection: update time stamp only if connection reaping is enabled
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-1764
>                 URL: https://issues.jboss.org/browse/JGRP-1764
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In TCPConnectionMap, {{updateLastAccessed()}} is called whenever a message is sent or received. This doesn't need to be done if connection reaping is 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 issues at jboss.org  Tue Jan 28 05:05:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Jan 2014 05:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1741) JGroups went into an infinite
	loop
In-Reply-To: <JIRA.12524990.1384350477000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524990.1384350477000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524990.1384350477000.17302.1390903528827@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939217#comment-12939217 ] 

Bela Ban commented on JGRP-1741:
--------------------------------

Try replacing MERGE2 with MERGE3. 
                
> JGroups went into an infinite loop
> ----------------------------------
>
>                 Key: JGRP-1741
>                 URL: https://issues.jboss.org/browse/JGRP-1741
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.5
>         Environment: Linux s0.law.di.unimi.it 2.6.32-358.18.1.el6.x86_64 #1 SMP Tue Aug 27 14:23:09 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Sebastiano Vigna
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> We experienced a severe problem with JGroups going into an infinite loop and locking all our threads trying to send messages.
> We had four agents running in parallel and exchanging messages. After about four days, for about half an hour the network between the agents was interrupted for unknown hardware reasons. Each agent started to suspect the others, and then, when the network restarted, found them again. Except s0, which logged
> 2013-11-13 04:26:47,017 443146923 WARN [Incoming-28,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.GMS - s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: not member of view [s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi|6]; discarding it
> We had then a couple of log like
> 013-11-13 04:26:47,017 443146923 DEBUG [OOB-1,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.STABLE - s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: received digest from s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi (digest=s2{1}@service:jmx:rmi:///jndi/rmi://192.168.0.22:9999/jmxrmi: [0 (0)], s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi: [0 (0)], s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi: [5353 (5353)]) which does not match my own digest (s2{1}@service:jmx:rmi:///jndi/rmi://192.168.0.22:9999/jmxrmi: [0 (0)], s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi: [0 (0)], s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: [1042 (1043)], s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi: [5352 (5352)]): ignoring digest and re-initializing own digest
> Then 
> 2013-11-13 04:26:47,681 443147587 WARN [OOB-25,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.UNICAST3 - s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: (requester=s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi) message s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi::963120278 not found in retransmission table of s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi:
> Then at some point JGroups went into an infinite loop. The application entirely stopped working?all thread waiting on a send(). We got something like 60G of logs like this:
> 2013-11-13 14:00:00,393 477540299 WARN [OOB-865,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.UNICAST3 - s0{1}@servi
> ce:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: (requester=s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi) message s3{1}@ser
> vice:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi::963120278 not found in retransmission table of s3{1}@service:jmx:rmi:///jndi/rmi://192.1
> 68.0.23:9999/jmxrmi:
> There was apparently an infinite loop. We have a (large) stack trace of the JVM that shows all our threads stuck in a send() like this:
> "ParsingThread-63" prio=10 tid=0x00007fdcceded000 nid=0xbd9b in Object.wait() [0x00007fdb76896000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
>         at java.lang.Object.wait(Native Method)
>         at org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:575)
>         - locked <0x00000004bd4c4c30> (a org.jgroups.protocols.FlowControl$Credit)
>         at org.jgroups.protocols.UFC.handleDownMessage(UFC.java:121)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:325)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:335)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:143)
>         at org.jgroups.protocols.RSVP.down(RSVP.java:142)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1022)
>         at org.jgroups.JChannel.down(JChannel.java:767)
>         at org.jgroups.JChannel.send(JChannel.java:432)
>         at it.unimi.dsi.jai4j.jgroups.JGroupsRemoteJobManager.process(JGroupsRemoteJobManager.java:144)
>         at it.unimi.dsi.jai4j.jgroups.JGroupsJobManager.submit(JGroupsJobManager.java:465)
>         at it.unimi.di.law.bubing.frontier.Frontier.enqueue(Frontier.java:642)
>         at it.unimi.di.law.bubing.frontier.ParsingThread$FrontierEnqueuer.enqueue(ParsingThread.java:204)
>         at it.unimi.di.law.bubing.frontier.ParsingThread.run(ParsingThread.java:392)
> You can find the full stack trace here:
> http://vigna.di.unimi.it/stack
> When the other agents exited a few hours later, however, the loop ended:
> 2013-11-13 14:04:13,088 477792994 DEBUG [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.GMS - s0{1}@ser
> vice:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: installing [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi|1043] [boss{0}
> @service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, s1{1}@service:jmx:rmi:/
> //jndi/rmi://192.168.0.21:9999/jmxrmi]
> 2013-11-13 14:04:13,088 477792994 DEBUG [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.NAKACK2 - s0{1}
> @service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: removed s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi from xmit_table
>  (not member anymore)
> 2013-11-13 14:04:13,088 477792994 DEBUG [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.FD_SOCK - VIEW_CH
> ANGE received: [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, 
> s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi]
> 2013-11-13 14:04:13,088 477792994 DEBUG [FD_SOCK pinger,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.FD_SOCK - sock
> et to s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi was closed gracefully
> 2013-11-13 14:04:13,088 477792994 DEBUG [FD_SOCK pinger,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.FD_SOCK - ping_dest is s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi, pingable_mbrs=[boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi]
> 2013-11-13 14:04:13,088 477792994 INFO [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] i.u.d.j.j.JGroupsJobManager - New JGroups view [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi|1043] [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi]
> After that, our agent was able to close the JGroups connection.
> We will be happy to provide any other information you might find useful. Unfortunately, replicating in vitro this behaviour is quite impossible.
> Our configuration follows:
> <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
>          mcast_port="${jgroups.udp.mcast_port:45588}"
>          tos="8"
>          ucast_recv_buf_size="5M"
>          ucast_send_buf_size="640K"
>          mcast_recv_buf_size="5M"
>          mcast_send_buf_size="640K"
>          loopback="true"
>          max_bundle_size="64K"
>          max_bundle_timeout="30"
>          ip_ttl="${jgroups.udp.ip_ttl:8}"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          timer_type="new3"
>          timer.min_threads="4"
>          timer.max_threads="10"
>          timer.keep_alive_time="3000"
>          timer.queue_max_size="500"
>          thread_pool.enabled="true"
>          thread_pool.min_threads="2"
>          thread_pool.max_threads="8"
>          thread_pool.keep_alive_time="5000"
>          thread_pool.queue_enabled="true"
>          thread_pool.queue_max_size="10000"
>          thread_pool.rejection_policy="discard"
>          oob_thread_pool.enabled="true"
>          oob_thread_pool.min_threads="1"
>          oob_thread_pool.max_threads="8"
>          oob_thread_pool.keep_alive_time="5000"
>          oob_thread_pool.queue_enabled="false"
>          oob_thread_pool.queue_max_size="100"
>          oob_thread_pool.rejection_policy="discard"/>
>     <PING timeout="2000"
>             num_initial_members="20"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD_ALL timeout="120000"
>             interval="10000"
>             />
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK2 xmit_interval="500"
>                     xmit_table_num_rows="100"
>                     xmit_table_msgs_per_row="2000"
>                     xmit_table_max_compaction_time="30000"
>                     max_msg_batch_size="500"
>                     use_mcast_xmit="false"
>                     discard_delivered_msgs="true"/>
>     <UNICAST3 xmit_interval="500"
>               xmit_table_num_rows="100"
>               xmit_table_msgs_per_row="2000"
>               xmit_table_max_compaction_time="60000"
>               conn_expiry_timeout="0"
>               max_msg_batch_size="500"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="4M"/>
>     <pbcast.GMS print_local_addr="true" join_timeout="3000"
>                 view_bundling="true"/>
>     <UFC max_credits="2M"
>          min_threshold="0.4"/>
>     <MFC max_credits="2M"
>          min_threshold="0.4"/>
>     <FRAG2 frag_size="60K"  />
>     <RSVP resend_interval="2000" timeout="10000"/>
> </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 issues at jboss.org  Tue Jan 28 05:11:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Jan 2014 05:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1741) JGroups went into an infinite
	loop
In-Reply-To: <JIRA.12524990.1384350477000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524990.1384350477000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524990.1384350477000.17318.1390903888601@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939219#comment-12939219 ] 

Bela Ban commented on JGRP-1741:
--------------------------------

Also, if this can be reproduced, I suggest run the latest JGroups (3.5 master or 3.4.2.Final) with the udp.xml shipped with it (except replace MERGE2 with MERGE3).
                
> JGroups went into an infinite loop
> ----------------------------------
>
>                 Key: JGRP-1741
>                 URL: https://issues.jboss.org/browse/JGRP-1741
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.5
>         Environment: Linux s0.law.di.unimi.it 2.6.32-358.18.1.el6.x86_64 #1 SMP Tue Aug 27 14:23:09 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
>            Reporter: Sebastiano Vigna
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> We experienced a severe problem with JGroups going into an infinite loop and locking all our threads trying to send messages.
> We had four agents running in parallel and exchanging messages. After about four days, for about half an hour the network between the agents was interrupted for unknown hardware reasons. Each agent started to suspect the others, and then, when the network restarted, found them again. Except s0, which logged
> 2013-11-13 04:26:47,017 443146923 WARN [Incoming-28,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.GMS - s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: not member of view [s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi|6]; discarding it
> We had then a couple of log like
> 013-11-13 04:26:47,017 443146923 DEBUG [OOB-1,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.STABLE - s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: received digest from s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi (digest=s2{1}@service:jmx:rmi:///jndi/rmi://192.168.0.22:9999/jmxrmi: [0 (0)], s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi: [0 (0)], s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi: [5353 (5353)]) which does not match my own digest (s2{1}@service:jmx:rmi:///jndi/rmi://192.168.0.22:9999/jmxrmi: [0 (0)], s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi: [0 (0)], s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: [1042 (1043)], s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi: [5352 (5352)]): ignoring digest and re-initializing own digest
> Then 
> 2013-11-13 04:26:47,681 443147587 WARN [OOB-25,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.UNICAST3 - s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: (requester=s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi) message s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi::963120278 not found in retransmission table of s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi:
> Then at some point JGroups went into an infinite loop. The application entirely stopped working?all thread waiting on a send(). We got something like 60G of logs like this:
> 2013-11-13 14:00:00,393 477540299 WARN [OOB-865,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.UNICAST3 - s0{1}@servi
> ce:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: (requester=s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi) message s3{1}@ser
> vice:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi::963120278 not found in retransmission table of s3{1}@service:jmx:rmi:///jndi/rmi://192.1
> 68.0.23:9999/jmxrmi:
> There was apparently an infinite loop. We have a (large) stack trace of the JVM that shows all our threads stuck in a send() like this:
> "ParsingThread-63" prio=10 tid=0x00007fdcceded000 nid=0xbd9b in Object.wait() [0x00007fdb76896000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
>         at java.lang.Object.wait(Native Method)
>         at org.jgroups.protocols.FlowControl$Credit.decrementIfEnoughCredits(FlowControl.java:575)
>         - locked <0x00000004bd4c4c30> (a org.jgroups.protocols.FlowControl$Credit)
>         at org.jgroups.protocols.UFC.handleDownMessage(UFC.java:121)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:325)
>         at org.jgroups.protocols.FlowControl.down(FlowControl.java:335)
>         at org.jgroups.protocols.FRAG2.down(FRAG2.java:143)
>         at org.jgroups.protocols.RSVP.down(RSVP.java:142)
>         at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1022)
>         at org.jgroups.JChannel.down(JChannel.java:767)
>         at org.jgroups.JChannel.send(JChannel.java:432)
>         at it.unimi.dsi.jai4j.jgroups.JGroupsRemoteJobManager.process(JGroupsRemoteJobManager.java:144)
>         at it.unimi.dsi.jai4j.jgroups.JGroupsJobManager.submit(JGroupsJobManager.java:465)
>         at it.unimi.di.law.bubing.frontier.Frontier.enqueue(Frontier.java:642)
>         at it.unimi.di.law.bubing.frontier.ParsingThread$FrontierEnqueuer.enqueue(ParsingThread.java:204)
>         at it.unimi.di.law.bubing.frontier.ParsingThread.run(ParsingThread.java:392)
> You can find the full stack trace here:
> http://vigna.di.unimi.it/stack
> When the other agents exited a few hours later, however, the loop ended:
> 2013-11-13 14:04:13,088 477792994 DEBUG [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.GMS - s0{1}@ser
> vice:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: installing [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi|1043] [boss{0}
> @service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, s1{1}@service:jmx:rmi:/
> //jndi/rmi://192.168.0.21:9999/jmxrmi]
> 2013-11-13 14:04:13,088 477792994 DEBUG [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.p.NAKACK2 - s0{1}
> @service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi: removed s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi from xmit_table
>  (not member anymore)
> 2013-11-13 14:04:13,088 477792994 DEBUG [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.FD_SOCK - VIEW_CH
> ANGE received: [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, 
> s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi]
> 2013-11-13 14:04:13,088 477792994 DEBUG [FD_SOCK pinger,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.FD_SOCK - sock
> et to s3{1}@service:jmx:rmi:///jndi/rmi://192.168.0.23:9999/jmxrmi was closed gracefully
> 2013-11-13 14:04:13,088 477792994 DEBUG [FD_SOCK pinger,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] o.j.p.FD_SOCK - ping_dest is s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi, pingable_mbrs=[boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi]
> 2013-11-13 14:04:13,088 477792994 INFO [Incoming-46,eu,s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi] i.u.d.j.j.JGroupsJobManager - New JGroups view [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi|1043] [boss{0}@service:jmx:rmi:///jndi/rmi://192.168.0.1:9998/jmxrmi, s0{1}@service:jmx:rmi:///jndi/rmi://192.168.0.20:9999/jmxrmi, s1{1}@service:jmx:rmi:///jndi/rmi://192.168.0.21:9999/jmxrmi]
> After that, our agent was able to close the JGroups connection.
> We will be happy to provide any other information you might find useful. Unfortunately, replicating in vitro this behaviour is quite impossible.
> Our configuration follows:
> <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
>          mcast_port="${jgroups.udp.mcast_port:45588}"
>          tos="8"
>          ucast_recv_buf_size="5M"
>          ucast_send_buf_size="640K"
>          mcast_recv_buf_size="5M"
>          mcast_send_buf_size="640K"
>          loopback="true"
>          max_bundle_size="64K"
>          max_bundle_timeout="30"
>          ip_ttl="${jgroups.udp.ip_ttl:8}"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          timer_type="new3"
>          timer.min_threads="4"
>          timer.max_threads="10"
>          timer.keep_alive_time="3000"
>          timer.queue_max_size="500"
>          thread_pool.enabled="true"
>          thread_pool.min_threads="2"
>          thread_pool.max_threads="8"
>          thread_pool.keep_alive_time="5000"
>          thread_pool.queue_enabled="true"
>          thread_pool.queue_max_size="10000"
>          thread_pool.rejection_policy="discard"
>          oob_thread_pool.enabled="true"
>          oob_thread_pool.min_threads="1"
>          oob_thread_pool.max_threads="8"
>          oob_thread_pool.keep_alive_time="5000"
>          oob_thread_pool.queue_enabled="false"
>          oob_thread_pool.queue_max_size="100"
>          oob_thread_pool.rejection_policy="discard"/>
>     <PING timeout="2000"
>             num_initial_members="20"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD_ALL timeout="120000"
>             interval="10000"
>             />
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK2 xmit_interval="500"
>                     xmit_table_num_rows="100"
>                     xmit_table_msgs_per_row="2000"
>                     xmit_table_max_compaction_time="30000"
>                     max_msg_batch_size="500"
>                     use_mcast_xmit="false"
>                     discard_delivered_msgs="true"/>
>     <UNICAST3 xmit_interval="500"
>               xmit_table_num_rows="100"
>               xmit_table_msgs_per_row="2000"
>               xmit_table_max_compaction_time="60000"
>               conn_expiry_timeout="0"
>               max_msg_batch_size="500"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="4M"/>
>     <pbcast.GMS print_local_addr="true" join_timeout="3000"
>                 view_bundling="true"/>
>     <UFC max_credits="2M"
>          min_threshold="0.4"/>
>     <MFC max_credits="2M"
>          min_threshold="0.4"/>
>     <FRAG2 frag_size="60K"  />
>     <RSVP resend_interval="2000" timeout="10000"/>
> </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 issues at jboss.org  Tue Jan 28 05:15:30 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Jan 2014 05:15:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the
	thread waiting
In-Reply-To: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501933.1380638415000.17342.1390904130224@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1711:
---------------------------

    Fix Version/s: Future
                       (was: 3.5)


Moved to future release. When you submit a pull request, we can move it to the current version (e.g. 3.5)
                
> DELAY2: Do not keep the thread waiting
> --------------------------------------
>
>                 Key: JGRP-1711
>                 URL: https://issues.jboss.org/browse/JGRP-1711
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: Future
>
>
> Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.
> As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.
> For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.
> Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 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 issues at jboss.org  Tue Jan 28 05:19:28 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Jan 2014 05:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1754) Large cluster tests on Google
 Compute Engine
In-Reply-To: <JIRA.12527588.1386696133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527588.1386696133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527588.1386696133000.17354.1390904368539@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1754:
---------------------------

        Summary: Large cluster tests on Google Compute Engine  (was: Large cluster tests)
    Description: Test a large JGroups cluster. Investigate *Google Compute Engine* (got a 1000$ voucher for testing). The latter is free if I can get hundreds or thousands of instances to run on a single physical box...  (was: Test a large JGroups cluster. Investigate *Google Compute Engine* (got a 1000$ voucher for testing) and *Docker*. The latter is free if I can get hundreds or thousands of instances to run on a single physical box...)

    
> Large cluster tests on Google Compute Engine
> --------------------------------------------
>
>                 Key: JGRP-1754
>                 URL: https://issues.jboss.org/browse/JGRP-1754
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Test a large JGroups cluster. Investigate *Google Compute Engine* (got a 1000$ voucher for testing). The latter is free if I can get hundreds or thousands of instances to run on a single physical box...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 05:55:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Tue, 28 Jan 2014 05:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.17466.1390906528965@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939231#comment-12939231 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Just a matter of time... I'll post it then.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 06:13:28 2014
From: issues at jboss.org (Hardy Ferentschik (JIRA))
Date: Tue, 28 Jan 2014 06:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2823) Upgrade Hibernate Validator
	to 5.0.3.Final
In-Reply-To: <JIRA.12530473.1390907520098@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530473.1390907520098@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530473.1390907520098.17477.1390907608736@jira02.app.mwc.hst.phx2.redhat.com>

Hardy Ferentschik created WFLY-2823:
---------------------------------------

             Summary: Upgrade Hibernate Validator to 5.0.3.Final
                 Key: WFLY-2823
                 URL: https://issues.jboss.org/browse/WFLY-2823
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Hardy Ferentschik
             Fix For: 8.0.0.Final


Hibernate Validator should be upgraded to avoid memory leak during re-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 issues at jboss.org  Tue Jan 28 06:19:28 2014
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Tue, 28 Jan 2014 06:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2451) Allow basic WS subsystem
 updates without requiring reload
In-Reply-To: <JIRA.12518170.1383757496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518170.1383757496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518170.1383757496000.17483.1390907968552@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939234#comment-12939234 ] 

Alessio Soldano commented on WFLY-2451:
---------------------------------------

PR against Kabir's wildfly-next: https://github.com/kabir/wildfly/pull/4
                
> Allow basic WS subsystem updates without requiring reload
> ---------------------------------------------------------
>
>                 Key: WFLY-2451
>                 URL: https://issues.jboss.org/browse/WFLY-2451
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 9.0.0.CR1
>
>
> Currently any change to the WS subsystem model requires reload for being applied to the runtime.
> It should be possible to actually perform some runtime updates without reload in some situations, basically when there's no WS deployment active yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 06:57:29 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 28 Jan 2014 06:57:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.17559.1390910249324@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFLY-880:
--------------------------------

    Fix Version/s: 8.0.0.Alpha2

    
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>             Fix For: 8.0.0.Alpha2
>
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 06:59:30 2014
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 28 Jan 2014 06:59:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.17568.1390910370981@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka resolved WFLY-880.
---------------------------------

    Resolution: Done


This was fixed with MSC upgrade.
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Richard Opalka
>              Labels: jboss
>             Fix For: 8.0.0.Alpha2
>
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 07:43:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 28 Jan 2014 07:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2799) Drop
 SystemMemoryUsageLoadMetric from mod_cluster subsystem
In-Reply-To: <JIRA.12530187.1390471579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530187.1390471579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530187.1390471579000.17696.1390913008572@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939256#comment-12939256 ] 

Radoslav Husar commented on WFLY-2799:
--------------------------------------

Updated PR to:

* keep it in the model, so that previous versions running with new DC are unaffected
* warn and ignore if people have it configured
                
> Drop SystemMemoryUsageLoadMetric from mod_cluster subsystem
> -----------------------------------------------------------
>
>                 Key: WFLY-2799
>                 URL: https://issues.jboss.org/browse/WFLY-2799
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Final
>
>
> See MODCLUSTER-288.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 09:59:29 2014
From: issues at jboss.org (Gunnar Morling (JIRA))
Date: Tue, 28 Jan 2014 09:59:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.18239.1390921169618@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939318#comment-12939318 ] 

Gunnar Morling commented on WFLY-2762:
--------------------------------------

Tested the fix by building WildFly from [Jozef's branch|https://github.com/jharting/wildfly/tree/WFLY-2762] and using that version to run the original test case in HV and can confirm that this fixes the issue. Thanks!
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:03:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 28 Jan 2014 11:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.18434.1390925009005@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939344#comment-12939344 ] 

Stuart Douglas commented on WFLY-2778:
--------------------------------------

Can you confirm the version of XNIO that you are using? (It is in the modules/system/layers/base/org/jboss/xnio/main directory)


                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:05:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 11:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.18446.1390925129144@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939345#comment-12939345 ] 

Jason Greene commented on WFLY-2778:
------------------------------------

Thanks for being patient with us. We really would like to see this COMPLETELY resolved before final is released. Unfortunately we have been unable to reproduce whatever incarnation you are seeing.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:09:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Tue, 28 Jan 2014 11:09:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.18461.1390925369107@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939347#comment-12939347 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

piece of cake:

{code}
wildfly/modules/system/layers/base/org/jboss/xnio/main$ ll
total 492
drwxr-xr-x 2 wildfly wildfly   4096 Jan 28 02:36 ./
drwxr-xr-x 5 wildfly wildfly   4096 Jan 28 02:36 ../
-rwxr-xr-x 1 wildfly wildfly   1466 Jan 28 02:36 module.xml*
-rwxr-xr-x 1 wildfly wildfly 491417 Jan 28 02:36 xnio-api-3.2.0.Final.jar*
{code}
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:09:29 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Tue, 28 Jan 2014 11:09:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-373) [backport JBMETA-371]
 DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530507.1390925363617@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530507.1390925363617@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530507.1390925363617.18464.1390925369214@jira02.app.mwc.hst.phx2.redhat.com>

Chris Dolphy created JBMETA-373:
-----------------------------------

             Summary: [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
                 Key: JBMETA-373
                 URL: https://issues.jboss.org/browse/JBMETA-373
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common
    Affects Versions: 7.0.4.Final
            Reporter: Chris Dolphy
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Final


The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".

This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Tue Jan 28 11:11:28 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Tue, 28 Jan 2014 11:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-373) [backport JBMETA-371]
 DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530507.1390925363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530507.1390925363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530507.1390925363000.18469.1390925488719@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Dolphy updated JBMETA-373:
--------------------------------

    Fix Version/s:     (was: 8.0.0.Final)

    
> [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-373
>                 URL: https://issues.jboss.org/browse/JBMETA-373
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4.Final
>            Reporter: Chris Dolphy
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Tue Jan 28 11:11:28 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Tue, 28 Jan 2014 11:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.18473.1390925488937@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939348#comment-12939348 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Jason,

no problem, meanwhile we switched to an setup with nginx resolving https to http in front of wildfly. We left one machine running in the old setup to support resolving this issue. So if I can help you let me know.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:13:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 11:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad
	passwords
In-Reply-To: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503730.1381946649000.18486.1390925608598@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939350#comment-12939350 ] 

Jason Greene commented on WFLY-2322:
------------------------------------

Do you still plan to do this. Is it still a blocker in your opinion?
                
> Update add-user to REJECT bad passwords
> ---------------------------------------
>
>                 Key: WFLY-2322
>                 URL: https://issues.jboss.org/browse/WFLY-2322
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:13:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 11:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1809) The security subsystem
 plugins use deprecated Infinispan API
In-Reply-To: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497821.1375428478000.18490.1390925608765@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939351#comment-12939351 ] 

Jason Greene commented on WFLY-1809:
------------------------------------

Paul is this still a blocker?
                
> The security subsystem plugins use deprecated Infinispan API
> ------------------------------------------------------------
>
>                 Key: WFLY-1809
>                 URL: https://issues.jboss.org/browse/WFLY-1809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: NadirX
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> org.jboss.as.security.plugins.JNDIBasedSecurityManagement uses a deprecated way of configuring an Infinispan cache which must 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 issues at jboss.org  Tue Jan 28 11:15:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 11:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.18494.1390925729687@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939352#comment-12939352 ] 

Jason Greene commented on WFLY-2762:
------------------------------------

Awesome. So whats the next steps on this?
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:17:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jan 2014 11:17:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.18509.1390925849001@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939353#comment-12939353 ] 

Jozef Hartinger commented on WFLY-2762:
---------------------------------------

The fix for this issue depends on WFLY-2761. I am therefore waiting for the PR for WFLY-2761 to be merged first so that I can send a PR for this issue afterwards.
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:31:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 11:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2824) Remove
 https://issues.apache.org/jira/browse/DIRAPI-125 workaround
In-Reply-To: <JIRA.12530511.1390926661164@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530511.1390926661164@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530511.1390926661164.18524.1390926689195@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2824:
--------------------------------------

             Summary: Remove https://issues.apache.org/jira/browse/DIRAPI-125 workaround 
                 Key: WFLY-2824
                 URL: https://issues.jboss.org/browse/WFLY-2824
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


As a workaround for an Apache DS bug we forked their LdapUrl class in the testsuite/integration/basic module. This JIRA is a reminder to check if the upstream bug is fixed and the fix is in the release WF uses; if so remove the workaround.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 11:31:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 11:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2824) Remove
 https://issues.apache.org/jira/browse/DIRAPI-125 workaround
In-Reply-To: <JIRA.12530511.1390926661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530511.1390926661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530511.1390926661000.18526.1390926689286@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2824:
-----------------------------------

    Fix Version/s: 8.0.1.Final

    
> Remove https://issues.apache.org/jira/browse/DIRAPI-125 workaround 
> -------------------------------------------------------------------
>
>                 Key: WFLY-2824
>                 URL: https://issues.jboss.org/browse/WFLY-2824
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.1.Final
>
>
> As a workaround for an Apache DS bug we forked their LdapUrl class in the testsuite/integration/basic module. This JIRA is a reminder to check if the upstream bug is fixed and the fix is in the release WF uses; if so remove the workaround.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 12:59:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 28 Jan 2014 12:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2445) Upgrade mod_cluster to
	1.3.0.Final
In-Reply-To: <JIRA.12518109.1383731634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518109.1383731634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518109.1383731634000.18651.1390931968594@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2445:
---------------------------------

    Summary: Upgrade mod_cluster to 1.3.0.Final  (was: Upgrade mod_cluster to 1.3.0.Alpha2)

    
> Upgrade mod_cluster to 1.3.0.Final
> ----------------------------------
>
>                 Key: WFLY-2445
>                 URL: https://issues.jboss.org/browse/WFLY-2445
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> See MODCLUSTER-367

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 13:09:30 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 28 Jan 2014 13:09:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-270) Use logger instead of [stdout]
 for JGroups GMS logger
In-Reply-To: <JIRA.12466283.1336752816000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466283.1336752816000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466283.1336752816000.18695.1390932570641@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-270:
--------------------------------

        Fix Version/s:     (was: 8.0.0.CR1)
                           (was: 8.0.0.Final)
    Affects Version/s: 8.0.0.Alpha1

    
> Use logger instead of [stdout] for JGroups GMS logger
> -----------------------------------------------------
>
>                 Key: WFLY-270
>                 URL: https://issues.jboss.org/browse/WFLY-270
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Trivial
>
> ...and possibly remove the unnecessary dash lines on the way.
> {noformat}
> [JBossINF] 12:11:12,677 INFO  [org.jboss.as.osgi] (MSC service thread 1-15) JBAS011907: Register module: Module "deployment.clusterbench-ee6.ear.clusterbench-ee6-ejb.jar:main" from Service Module Loader
> [JBossINF] 12:11:13,142 INFO  [stdout] (ChannelService lifecycle - 1) 
> [JBossINF] 12:11:13,142 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,142 INFO  [stdout] (ChannelService lifecycle - 1) GMS: address=perf18/web, cluster=web, physical address=10.16.90.54:55200
> [JBossINF] 12:11:13,143 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,209 INFO  [stdout] (ChannelService lifecycle - 1) 
> [JBossINF] 12:11:13,209 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,209 INFO  [stdout] (ChannelService lifecycle - 1) GMS: address=perf18/ejb, cluster=ejb, physical address=10.16.90.54:55200
> [JBossINF] 12:11:13,210 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,441 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
> {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 issues at jboss.org  Tue Jan 28 13:25:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2735) read-operation-names causes
 NullPointerException
In-Reply-To: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529095.1389360809000.18705.1390933528700@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2735:
-----------------------------------

    Summary: read-operation-names causes NullPointerException  (was: read-operation-names casues NullPointerException)

    
> read-operation-names causes NullPointerException
> ------------------------------------------------
>
>                 Key: WFLY-2735
>                 URL: https://issues.jboss.org/browse/WFLY-2735
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
>         at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>         at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         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.1.Final.jar:2.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 issues at jboss.org  Tue Jan 28 13:25:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2735) read-operation-names causes
 NullPointerException
In-Reply-To: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529095.1389360809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529095.1389360809000.18708.1390933528843@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2735:
-----------------------------------

    Affects Version/s: 8.0.0.CR1
                           (was: 8.0.0.Final)

    
> read-operation-names causes NullPointerException
> ------------------------------------------------
>
>                 Key: WFLY-2735
>                 URL: https://issues.jboss.org/browse/WFLY-2735
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Silvert
>            Assignee: Brian Stansberry
>
> CLI command> /core-service=*/:read-operation-names
> 08:27:16,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-operation-names") failed - address: ([("cor
> e-service" => "*")]): java.lang.NullPointerException
>         at org.jboss.as.controller.operations.global.ReadOperationNamesHandler.execute(ReadOperationNamesHandler.java:78) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0
> .0.Final-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSH
> OT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNA
> PSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Fin
> al-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-
> controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-con
> troller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>         at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_15]
>         at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-c
> ontroller-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHO
> T]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-S
> NAPSHOT]
>         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.1.Final.jar:2.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 issues at jboss.org  Tue Jan 28 13:29:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 13:29:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2761) Make it possible for static
 cdi-enabled modules to see the beans in top-level deployments
In-Reply-To: <JIRA.12529575.1389867009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529575.1389867009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529575.1389867009000.18713.1390933768806@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939374#comment-12939374 ] 

Jason Greene commented on WFLY-2761:
------------------------------------

I just merged that PR. Thanks 
                
> Make it possible for static cdi-enabled modules to see the beans in top-level deployments
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2761
>                 URL: https://issues.jboss.org/browse/WFLY-2761
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.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 issues at jboss.org  Tue Jan 28 13:31:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 13:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.18717.1390933888658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939375#comment-12939375 ] 

Jason Greene commented on WFLY-2762:
------------------------------------

Ok done :)
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 13:41:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.18731.1390934488913@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939377#comment-12939377 ] 

Brian Stansberry commented on WFLY-2785:
----------------------------------------

You should discuss this with Emanuel Muckenhuber.
                
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 13:45:30 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:45:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2647) Update HornetQ to 2.4.0.Final
In-Reply-To: <JIRA.12527850.1386874759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527850.1386874759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527850.1386874759000.18744.1390934729999@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2647:
-----------------------------------

     Issue Type: Component  Upgrade  (was: Feature Request)
    Component/s: JMS

    
> Update HornetQ to 2.4.0.Final
> -----------------------------
>
>                 Key: WFLY-2647
>                 URL: https://issues.jboss.org/browse/WFLY-2647
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> I'm setting this as blocker as I think WF final should come with HQ 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 issues at jboss.org  Tue Jan 28 13:45:30 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:45:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2647) Update HornetQ to 2.4.0.Final
In-Reply-To: <JIRA.12527850.1386874759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527850.1386874759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527850.1386874759000.18748.1390934730245@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2647.
------------------------------------

    Resolution: Done


The pom shows this is done.
                
> Update HornetQ to 2.4.0.Final
> -----------------------------
>
>                 Key: WFLY-2647
>                 URL: https://issues.jboss.org/browse/WFLY-2647
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> I'm setting this as blocker as I think WF final should come with HQ 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 issues at jboss.org  Tue Jan 28 13:49:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1958) Provide machine readable
 referential RBAC 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.18753.1390934968885@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1958:
-----------------------------------

    Summary: Provide machine readable referential RBAC document with information of default security constrains  (was: Provide machine readable referential document with information of default security constrains)

    
> Provide machine readable referential RBAC document with information of default security constrains
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1958
>                 URL: https://issues.jboss.org/browse/WFLY-1958
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 13:49:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1958) Provide machine readable
 referential RBAC 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.18756.1390934969057@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1958:
-----------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Feature Request  (was: Sub-task)

    
> Provide machine readable referential RBAC document with information of default security constrains
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1958
>                 URL: https://issues.jboss.org/browse/WFLY-1958
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 13:49:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1958) Provide machine readable
 referential RBAC 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.18759.1390934969262@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1958:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Provide machine readable referential RBAC document with information of default security constrains
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1958
>                 URL: https://issues.jboss.org/browse/WFLY-1958
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 9.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 issues at jboss.org  Tue Jan 28 13:49:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:49:29 -0500 (EST)
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.18761.1390934969364@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:
-----------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Task  (was: Sub-task)

    
> Remove ConstrainedResourceDefinition, add methods to ResourceDefinition
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1857
>                 URL: https://issues.jboss.org/browse/WFLY-1857
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 13:49:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:49:29 -0500 (EST)
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.18762.1390934969397@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:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Remove ConstrainedResourceDefinition, add methods to ResourceDefinition
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1857
>                 URL: https://issues.jboss.org/browse/WFLY-1857
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>              Labels: RBAC-WF-only
>             Fix For: 9.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 issues at jboss.org  Tue Jan 28 13:51:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:51:28 -0500 (EST)
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.18765.1390935088837@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:
-----------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Feature Request  (was: Sub-task)

    
> Ability to configure a custom RBAC implementation
> -------------------------------------------------
>
>                 Key: WFLY-2002
>                 URL: https://issues.jboss.org/browse/WFLY-2002
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Optional
>              Labels: RBAC-WF-only
>             Fix For: 9.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 issues at jboss.org  Tue Jan 28 13:51:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1867) Provide access control
	documentation
In-Reply-To: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498454.1376383935000.18770.1390935089208@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1867:
-----------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Task  (was: Sub-task)

    
> Provide access control documentation
> ------------------------------------
>
>                 Key: WFLY-1867
>                 URL: https://issues.jboss.org/browse/WFLY-1867
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> The access control features need to be properly documented

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 13:51:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 13:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1867) Provide access control
	documentation
In-Reply-To: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498454.1376383935000.18773.1390935089325@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1867:
-----------------------------------

    Fix Version/s: No Release
                       (was: 8.0.0.Final)

    
> Provide access control documentation
> ------------------------------------
>
>                 Key: WFLY-1867
>                 URL: https://issues.jboss.org/browse/WFLY-1867
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: No Release
>
>
> The access control features need to be properly documented

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 14:15:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 management 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.18801.1390936529327@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1895:
-----------------------------------

    Summary: Provide a "default" role for management users with no other role specified  (was: Provide a "default" role for users with no other role specified)

    
> Provide a "default" role for management users with no other role specified
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 14:15:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 management 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.18803.1390936529457@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1895:
-----------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Enhancement  (was: Sub-task)

    
> Provide a "default" role for management users with no other role specified
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 14:15:30 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:15:30 -0500 (EST)
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.18822.1390936530566@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 resolved WFLY-490.
-----------------------------------

    Resolution: Done

    
> Domain Management Role Based Access Control
> -------------------------------------------
>
>                 Key: WFLY-490
>                 URL: https://issues.jboss.org/browse/WFLY-490
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: Authorization
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 14:19:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:19:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 management 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.18829.1390936769593@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939389#comment-12939389 ] 

Brian Stansberry commented on WFLY-1895:
----------------------------------------

With no security realm configured on the interface and the 'simple' provider chosen, behavior is as expected: anyone can connect and administer.

With no security realm configured on the interface and the 'rbac' provider chosen, console behavior is pretty good. The user gets an unauthorized dialogue with no prompt to authenticate. Minor flaw is that dialogue is dismissed with a button that says "Logout" which in incorrect, since in this case the user didn't log in.

With no security realm configured on the interface and the 'rbac' provider chosen, CLI behavior is not very intuitive. You can connect and you get the [standalone at localhost:9990 /] prompt. But if you attempt to do anything the requires server-side work you get various errors indicating your aren't authorized.
                
> Provide a "default" role for management users with no other role specified
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 14:21:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 management 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.18836.1390936888867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1895:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 8.0.0.Final)

    
> Provide a "default" role for management users with no other role specified
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.1.Final
>
>
> 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 issues at jboss.org  Tue Jan 28 14:23:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1555) Update log4j-jboss-logmanager
In-Reply-To: <JIRA.12494593.1371596804000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494593.1371596804000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494593.1371596804000.18843.1390937008734@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939390#comment-12939390 ] 

Brian Stansberry commented on WFLY-1555:
----------------------------------------

What's the status on this?
                
> Update log4j-jboss-logmanager
> -----------------------------
>
>                 Key: WFLY-1555
>                 URL: https://issues.jboss.org/browse/WFLY-1555
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Build System, Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> There are upstream bug fixes in the log4j-jboss-logmanager project that should be included in the final release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 14:25:29 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 28 Jan 2014 14:25:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1555) Update log4j-jboss-logmanager
In-Reply-To: <JIRA.12494593.1371596804000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494593.1371596804000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494593.1371596804000.18849.1390937129511@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939391#comment-12939391 ] 

James Perkins commented on WFLY-1555:
-------------------------------------

I just need [~dmlloyd] to do a release :)
                
> Update log4j-jboss-logmanager
> -----------------------------
>
>                 Key: WFLY-1555
>                 URL: https://issues.jboss.org/browse/WFLY-1555
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Build System, Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> There are upstream bug fixes in the log4j-jboss-logmanager project that should be included in the final release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 14:25:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:25:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2675) Boot (???) deadlock
In-Reply-To: <JIRA.12528282.1387486800000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528282.1387486800000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528282.1387486800000.18853.1390937129696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2675.
------------------------------------

    Resolution: Done


Resolved with upgrade to MSC 1.2.0.CR2 or later. Master is now on .Final.
                
> Boot (???) deadlock
> -------------------
>
>                 Key: WFLY-2675
>                 URL: https://issues.jboss.org/browse/WFLY-2675
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> A deadlock occurred during a testsuite/domain run:
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=7356&buildTypeId=WFPR
> The test hung during domain shutdown:
> {code}
> at org.jboss.as.test.integration.domain.management.util.ProcessWrapper.waitFor(ProcessWrapper.java:97)
> 	at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.stop(DomainLifecycleUtil.java:312)
> 	- locked <0xa7ac7318> (a org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil)
> 	at org.jboss.as.test.integration.domain.management.util.DomainTestSupport.stop(DomainTestSupport.java:370)
> 	at org.jboss.as.test.integration.domain.ServerManagementTestCase.tearDownDomain(ServerManagementTestCase.java:116)
> {code}
> It's possible that's just when the test client hung, and the issue may have occurred at some earlier point. On the thread dump of all processes, one of the servers under the slave HC reported this:
> {code}
> Found one Java-level deadlock:
> =============================
> "Controller Boot Thread":
>   waiting to lock monitor 0x9a2566e0 (object 0xafdc6028, a org.jboss.msc.service.ServiceControllerImpl),
>   which is held by "MSC service thread 1-1"
> "MSC service thread 1-1":
>   waiting to lock monitor 0x9a2575b8 (object 0xb014ea70, a java.lang.Object),
>   which is held by "Controller Boot Thread"
> Java stack information for the threads listed above:
> ===================================================
> "Controller Boot Thread":
> 	at org.jboss.msc.service.ServiceControllerImpl.removeMonitorNoCallback(ServiceControllerImpl.java:1486)
> 	- waiting to lock <0xafdc6028> (a org.jboss.msc.service.ServiceControllerImpl)
> 	at org.jboss.msc.service.StabilityMonitor.clear(StabilityMonitor.java:175)
> 	- locked <0xb014ea70> (a java.lang.Object)
> 	at org.jboss.as.server.BootstrapListener.printBootStatistics(BootstrapListener.java:70)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:345)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-1":
> 	at org.jboss.msc.service.StabilityMonitor.removeControllerNoCallback(StabilityMonitor.java:151)
> 	- waiting to lock <0xb014ea70> (a java.lang.Object)
> 	at org.jboss.msc.service.ServiceControllerImpl.transition(ServiceControllerImpl.java:688)
> 	at org.jboss.msc.service.ServiceControllerImpl$RemoveTask.run(ServiceControllerImpl.java:2267)
> 	- locked <0xafdc6028> (a org.jboss.msc.service.ServiceControllerImpl)
> 	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:724)
> {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 issues at jboss.org  Tue Jan 28 14:29:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:29:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-156) Unable to start jboss AS on
 windows if installed on path containig non-ascii characters
In-Reply-To: <JIRA.12481936.1357295043000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481936.1357295043000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481936.1357295043000.18870.1390937368611@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-156:
----------------------------------

    Fix Version/s:     (was: 8.0.0.Final)

    
> Unable to start  jboss AS on windows if installed on path containig non-ascii characters
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-156
>                 URL: https://issues.jboss.org/browse/WFLY-156
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: windows 2008 x64
>            Reporter: Ales Kolenc
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> 1.) Install jboss into a folder containing non-ascii characters. (i.e. "C:\Test?").
> 2.) run standalone.bat
> C:\Test?\jboss-as-7.1.1.Final\bin>set JAVA_HOME=C:\Program Files\Java\jre7
> C:\Test?\jboss-as-7.1.1.Final\bin>standalone.bat
> Calling "C:\Test?\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: C:\Test?\jboss-as-7.1.1.Final
>   JAVA: C:\Program Files\Java\jre7\bin\java
>   JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Error: Unable to access jarfile C:\Test?\jboss-as-7.1.1.Final\jboss-modules.jar
> Press any key to continue . . .
> C:\Test?\jboss-as-7.1.1.Final\bin>
> 3.) pleas note that: "Test?" used in path -> '?' does not bellong to system locale code page. E.g.: char '?' is in CP 932, system locale code page used 437/1252,..
> 4.) i would also like to add that jboss does not start if it installed in "normal" folder, but JBOSS_CONFIG_DIR && JBOSS_LOG_DIR are set to folder with non-ascii characters:
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_LOG_DIR=c:\Test?
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_CONFIG_DIR=c:\Test?\configuration
> c:\test\jboss-as-7.1.1.Final\bin>dir %JBOSS_CONFIG_DIR%
>  Volume in drive C has no label.
>  Volume Serial Number is 2C2F-FA6F
>  Directory of c:\Test?\configuration
> 01/04/2013  02:34 AM    <DIR>          .
> 01/04/2013  02:34 AM    <DIR>          ..
> 01/04/2013  01:42 AM               634 application-roles.properties
> 01/04/2013  01:42 AM               812 application-users.properties
> 01/04/2013  01:42 AM             2,042 logging.properties
> 01/04/2013  01:42 AM               836 mgmt-users.properties
> 01/04/2013  01:42 AM            27,024 standalone-full-ha.xml
> 01/04/2013  01:42 AM            20,794 standalone-full.xml
> 01/04/2013  01:42 AM            20,358 standalone-ha.xml
> 01/04/2013  01:42 AM            15,372 standalone.xml
> 01/04/2013  02:34 AM    <DIR>          standalone_xml_history
>                8 File(s)         87,872 bytes
>                3 Dir(s)  20,185,866,240 bytes free
> c:\test\jboss-as-7.1.1.Final\bin>standalone.bat -Djboss.server.config.dir=%JBOSS_CONFIG_DIR%
> Calling "c:\test\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: c:\test\jboss-as-7.1.1.Final
>   JAVA: C:\Program Files\Java\jre7\bin\java
>   JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Unable to read the logging configuration from 'file:c:\Test?\configuration/logging.properties' (java.io.FileNotFoundException: c:\Test?\configuration\logging.properties (The filename, directory name, or volume label syntax is incorrect))
> java.lang.IllegalStateException: JBAS018701: Configuration directory does not exist: c:\Test?\configuration
>         at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:371)
>         at org.jboss.as.server.Main.determineEnvironment(Main.java:242)
>         at org.jboss.as.server.Main.main(Main.java:83)
>         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 org.jboss.modules.Module.run(Module.java:260)
>         at org.jboss.modules.Main.main(Main.java:291)
> Press any key to continue . . .
> c:\test\jboss-as-7.1.1.Final\bin>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 28 14:29:28 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 14:29:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-156) Unable to start jboss AS on
 windows if installed on path containig non-ascii characters
In-Reply-To: <JIRA.12481936.1357295043000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481936.1357295043000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481936.1357295043000.18875.1390937368805@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-156:
----------------------------------

    Fix Version/s: Awaiting Volunteers
                       (was: 8.0.0.CR1)

    
> Unable to start  jboss AS on windows if installed on path containig non-ascii characters
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-156
>                 URL: https://issues.jboss.org/browse/WFLY-156
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>         Environment: windows 2008 x64
>            Reporter: Ales Kolenc
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: Awaiting Volunteers
>
>
> 1.) Install jboss into a folder containing non-ascii characters. (i.e. "C:\Test?").
> 2.) run standalone.bat
> C:\Test?\jboss-as-7.1.1.Final\bin>set JAVA_HOME=C:\Program Files\Java\jre7
> C:\Test?\jboss-as-7.1.1.Final\bin>standalone.bat
> Calling "C:\Test?\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: C:\Test?\jboss-as-7.1.1.Final
>   JAVA: C:\Program Files\Java\jre7\bin\java
>   JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Error: Unable to access jarfile C:\Test?\jboss-as-7.1.1.Final\jboss-modules.jar
> Press any key to continue . . .
> C:\Test?\jboss-as-7.1.1.Final\bin>
> 3.) pleas note that: "Test?" used in path -> '?' does not bellong to system locale code page. E.g.: char '?' is in CP 932, system locale code page used 437/1252,..
> 4.) i would also like to add that jboss does not start if it installed in "normal" folder, but JBOSS_CONFIG_DIR && JBOSS_LOG_DIR are set to folder with non-ascii characters:
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_LOG_DIR=c:\Test?
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_CONFIG_DIR=c:\Test?\configuration
> c:\test\jboss-as-7.1.1.Final\bin>dir %JBOSS_CONFIG_DIR%
>  Volume in drive C has no label.
>  Volume Serial Number is 2C2F-FA6F
>  Directory of c:\Test?\configuration
> 01/04/2013  02:34 AM    <DIR>          .
> 01/04/2013  02:34 AM    <DIR>          ..
> 01/04/2013  01:42 AM               634 application-roles.properties
> 01/04/2013  01:42 AM               812 application-users.properties
> 01/04/2013  01:42 AM             2,042 logging.properties
> 01/04/2013  01:42 AM               836 mgmt-users.properties
> 01/04/2013  01:42 AM            27,024 standalone-full-ha.xml
> 01/04/2013  01:42 AM            20,794 standalone-full.xml
> 01/04/2013  01:42 AM            20,358 standalone-ha.xml
> 01/04/2013  01:42 AM            15,372 standalone.xml
> 01/04/2013  02:34 AM    <DIR>          standalone_xml_history
>                8 File(s)         87,872 bytes
>                3 Dir(s)  20,185,866,240 bytes free
> c:\test\jboss-as-7.1.1.Final\bin>standalone.bat -Djboss.server.config.dir=%JBOSS_CONFIG_DIR%
> Calling "c:\test\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: c:\test\jboss-as-7.1.1.Final
>   JAVA: C:\Program Files\Java\jre7\bin\java
>   JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Unable to read the logging configuration from 'file:c:\Test?\configuration/logging.properties' (java.io.FileNotFoundException: c:\Test?\configuration\logging.properties (The filename, directory name, or volume label syntax is incorrect))
> java.lang.IllegalStateException: JBAS018701: Configuration directory does not exist: c:\Test?\configuration
>         at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:371)
>         at org.jboss.as.server.Main.determineEnvironment(Main.java:242)
>         at org.jboss.as.server.Main.main(Main.java:83)
>         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 org.jboss.modules.Module.run(Module.java:260)
>         at org.jboss.modules.Main.main(Main.java:291)
> Press any key to continue . . .
> c:\test\jboss-as-7.1.1.Final\bin>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Tue Jan 28 15:11:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Tue, 28 Jan 2014 15:11:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2496) Concurrent access to
 ModuleSpecification causes race condition
In-Reply-To: <JIRA.12524939.1384289082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524939.1384289082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524939.1384289082000.18957.1390939889003@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939405#comment-12939405 ] 

Jason Greene commented on WFLY-2496:
------------------------------------

I am not sure its safe for a sub deployment to modify another sub deployments module spec, it might have already created a module. I need to look into this.
                
> Concurrent access to ModuleSpecification causes race condition
> --------------------------------------------------------------
>
>                 Key: WFLY-2496
>                 URL: https://issues.jboss.org/browse/WFLY-2496
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> [ModuleSpecification|https://github.com/wildfly/wildfly/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecification.java] does not use any form of synchronization to protect its mutable state yet may be used from multiple threads in multi-module deployment when a DeploymentUnitProcessor touches ModuleSpecification of a different deployment unit which is processed at that moment.
> Here is an example of such access: https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFDependencyProcessor.java#L93
> Here's how I think this problem manifests:
> {noformat}
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:284) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:220) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:125) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:88) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         ... 5 more
> {noformat}
> and here's my attempt to verify concurrent access by changing the code slightly to deadlock on concurrent access: 
> {noformat}
> "MSC service thread 1-6":
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x00000000f742ba28> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:170)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
>         - locked <0x00000000f69a8e88> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:744)
> "MSC service thread 1-3":
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x00000000f742ba58> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:175)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
>         - locked <0x00000000f6782960> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:744)
> {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 issues at jboss.org  Tue Jan 28 15:45:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 28 Jan 2014 15:45:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.19001.1390941928908@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBMETA-371:
-------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056799, https://bugzilla.redhat.com/show_bug.cgi?id=1058959  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1056799)

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Tue Jan 28 16:23:29 2014
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jan 2014 16:23:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2762) Injection of
 application-provided CDI bean into extension-provided bean fails
In-Reply-To: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529576.1389867612000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529576.1389867612000.19060.1390944209879@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939416#comment-12939416 ] 

Jozef Hartinger commented on WFLY-2762:
---------------------------------------

PR sent
                
> Injection of application-provided CDI bean into extension-provided bean fails
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2762
>                 URL: https://issues.jboss.org/browse/WFLY-2762
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>            Reporter: Gunnar Morling
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> When an application provides a CDI bean, injection of this bean into another bean provided by a portable extension (which is attached to this application) fails.
> The specific use case is the PE for Hibernate Validator which contains a class {{ValidationInterceptor}} with an injection point of type {{j.v.Validator}}. If the application happens to provide a producer for that type, deployment of the application fails with the following error message:
> {quote}
> WELD-001408: Unsatisfied dependencies for type Validator with qualifiers @Default
>     at injection point \[UnbackedAnnotatedField\] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator
> {quote}
> A test case can be found [here|https://github.com/gunnarmorling/hibernate-validator/tree/injection-issue-test]. To execute it, pull that branch and run:
> {code}
> mvn clean install -pl integration -Dit.test=InjectionIssueIT
> {code}
> The deployment of that Arquillian test fails with the error above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 16:47:29 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 28 Jan 2014 16:47:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2825) Create operations to view the
 host and process controller log files
In-Reply-To: <JIRA.12530533.1390945602690@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530533.1390945602690@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530533.1390945602690.19115.1390945649139@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2825:
-----------------------------------

             Summary: Create operations to view the host and process controller log files
                 Key: WFLY-2825
                 URL: https://issues.jboss.org/browse/WFLY-2825
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Domain Management
            Reporter: James Perkins
            Assignee: James Perkins


Operations need to exist somewhere so the {{host-controller.log}} and {{process-controller.log}} files can be read with a management operation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 16:49:28 2014
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 28 Jan 2014 16:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2826) The list-log-files operation
 should have an option for sorting the results
In-Reply-To: <JIRA.12530534.1390945737103@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530534.1390945737103@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530534.1390945737103.19121.1390945768755@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2826:
-----------------------------------

             Summary: The list-log-files operation should have an option for sorting the results
                 Key: WFLY-2826
                 URL: https://issues.jboss.org/browse/WFLY-2826
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


Currently the {{list-log-files}} operation sorts the results by the file name. The output includes the size and the last modified date. The results should be sortable by these fields too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 17:39:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 17:39:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-244) Undertow Integration Tracker
In-Reply-To: <JIRA.12487782.1363958280000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487782.1363958280000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487782.1363958280000.19367.1390948768880@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-244:
-----------------------------

    Fix Version/s: 8.0.0.Final
                       (was: 8.0.0.CR1)

    
> Undertow Integration Tracker
> ----------------------------
>
>                 Key: WFLY-244
>                 URL: https://issues.jboss.org/browse/WFLY-244
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> Tracking issue for all issues related to undertow integration.
> as part of https://github.com/wildfly/wildfly/pull/4810 there tests removed that need to be re-added as part of this tracking 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 issues at jboss.org  Tue Jan 28 17:39:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 17:39:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-244) Undertow Integration Tracker
In-Reply-To: <JIRA.12487782.1363958280000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487782.1363958280000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487782.1363958280000.19365.1390948768839@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-244:
-----------------------------

    Fix Version/s:     (was: 8.0.0.Final)

    
> Undertow Integration Tracker
> ----------------------------
>
>                 Key: WFLY-244
>                 URL: https://issues.jboss.org/browse/WFLY-244
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Tracking issue for all issues related to undertow integration.
> as part of https://github.com/wildfly/wildfly/pull/4810 there tests removed that need to be re-added as part of this tracking 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 issues at jboss.org  Tue Jan 28 17:41:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 17:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-145) User insn't properly informed
 that APR is used
In-Reply-To: <JIRA.12456638.1326707373000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12456638.1326707373000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456638.1326707373000.19379.1390948888809@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-145.
----------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Out of Date


WildFly is not using jbossweb anymore.
                
> User insn't properly informed that APR is used
> ----------------------------------------------
>
>                 Key: WFLY-145
>                 URL: https://issues.jboss.org/browse/WFLY-145
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>            Reporter: Rostislav Svoboda
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Final
>
>
> AS7 log doesn't show sufficient information that APR is used or not. Currently the only clue is that org.apache.coyote.http11.Http11AprProtocol is used instead of org.apache.coyote.http11.Http11Protocol. But it's implementation details and many users can miss that.
> Add log message to inform users if APR is used or not!
> For example APR affect https connector definition which must use openssl based keys and not keystore. And if users do not know APR is used they can be easily confused and blame AS7 as broken.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 17:41:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 17:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-305) Implement mail inflow
In-Reply-To: <JIRA.12462152.1332335330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462152.1332335330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462152.1332335330000.19388.1390948889061@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-305:
-----------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 8.0.0.CR1)
                       (was: 8.0.0.Final)

    
> Implement mail inflow
> ---------------------
>
>                 Key: WFLY-305
>                 URL: https://issues.jboss.org/browse/WFLY-305
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.1.Final
>
>
> in previous versions of as we had mail-ra resource adapter that added functionality of handling inflow mails.
> there is implementation of this ironjacamar so the code could be reused.
> Resource addapter could/should be added the same way hornetq addapter is added in messaging subsystem.
> code and documentation from ironjacamer
> https://svn.jboss.org/repos/jbossas/projects/jboss-jca/trunk/adapters/src/main/java/org/jboss/jca/adapters/mail/
> http://docs.jboss.org/ironjacamar/userguide/1.1/en-US/html/introduction.html#overview_inbound

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 17:43:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 17:43:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-301) Undertow management API
In-Reply-To: <JIRA.12489432.1366009861000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489432.1366009861000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489432.1366009861000.19408.1390949009146@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-301:
-----------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> Undertow management API
> -----------------------
>
>                 Key: WFLY-301
>                 URL: https://issues.jboss.org/browse/WFLY-301
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Final
>
>
> Expose undertow subsystem management opertions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 17:47:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Jan 2014 17:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-84) Jasper using wrong
 ProtectionDomain for compiled JSP
In-Reply-To: <JIRA.12486586.1362598770000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486586.1362598770000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486586.1362598770000.19413.1390949248696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-84.
-----------------------------

    Fix Version/s:     (was: 8.0.0.Final)
       Resolution: Done


given that we do pass tests under security manger now, this should be resolved.
                
> Jasper using wrong ProtectionDomain for compiled JSP
> ----------------------------------------------------
>
>                 Key: WFLY-84
>                 URL: https://issues.jboss.org/browse/WFLY-84
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.CR1
>
>
> Compiled JSPs loaded via JasperLoader appear to be using a different ProtectionDomain than the rest of the WAR deployment.  I think it should probably be using a PD which contains the permissions from the deployment's ClassLoader, and probably the CodeSource from the deployment unit from which the JSP file originated.  This will ensure that permissions set via deployment descriptor and/or the management model will take proper effect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Tue Jan 28 19:01:29 2014
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Jan 2014 19:01:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2804) Add -u and -p shortcuts to
	jboss-cli
In-Reply-To: <JIRA.12530216.1390493394000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530216.1390493394000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530216.1390493394000.19456.1390953689104@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2804:
-----------------------------------

    Assignee: carmelo aprile

    
> Add -u and -p shortcuts to jboss-cli
> ------------------------------------
>
>                 Key: WFLY-2804
>                 URL: https://issues.jboss.org/browse/WFLY-2804
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Arun Gupta
>            Assignee: carmelo aprile
>            Priority: Minor
>
> jboss-cli only provides --user and --password as the options. It would be convenient to add -u and -p as shortcut options as this will bring consistency with add-user 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 issues at jboss.org  Wed Jan 29 00:51:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 29 Jan 2014 00:51:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2804) Add -u and -p shortcuts to
	jboss-cli
In-Reply-To: <JIRA.12530216.1390493394000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530216.1390493394000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530216.1390493394000.19590.1390974688883@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2804:
------------------------------------

    Component/s: CLI

    
> Add -u and -p shortcuts to jboss-cli
> ------------------------------------
>
>                 Key: WFLY-2804
>                 URL: https://issues.jboss.org/browse/WFLY-2804
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Arun Gupta
>            Assignee: carmelo aprile
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> jboss-cli only provides --user and --password as the options. It would be convenient to add -u and -p as shortcut options as this will bring consistency with add-user 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 issues at jboss.org  Wed Jan 29 02:49:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 29 Jan 2014 02:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2595) Logging DUP leaking class
	loaders
In-Reply-To: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526656.1386009889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526656.1386009889000.19617.1390981768854@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939479#comment-12939479 ] 

RH Bugzilla Integration commented on WFLY-2595:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1049074|https://bugzilla.redhat.com/show_bug.cgi?id=1049074] from ON_QA to VERIFIED
                
> Logging DUP leaking class loaders
> ---------------------------------
>
>                 Key: WFLY-2595
>                 URL: https://issues.jboss.org/browse/WFLY-2595
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 03:07:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 29 Jan 2014 03:07:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.19641.1390982849359@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939483#comment-12939483 ] 

RH Bugzilla Integration commented on WFLY-2753:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1053382|https://bugzilla.redhat.com/show_bug.cgi?id=1053382] from ON_QA to VERIFIED
                
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 04:05:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Wed, 29 Jan 2014 04:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.19788.1390986328781@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Babacek updated WFLY-2591:
---------------------------------

    Affects Version/s: 8.0.0.Final

    
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 04:11:28 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 29 Jan 2014 04:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is
 not writing data to store after removing from map in memory
In-Reply-To: <JIRA.12530574.1390986627142@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530574.1390986627142@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530574.1390986627142.19810.1390986688626@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created SECURITY-788:
-------------------------------------

             Summary: PicketBoxSecurityVault is not writing data to store after removing from map in memory
                 Key: SECURITY-788
                 URL: https://issues.jboss.org/browse/SECURITY-788
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PicketBox
    Affects Versions: PicketBox_4_0_20.Final
            Reporter: Peter Skopek
            Assignee: Peter Skopek
             Fix For: PicketBox_4_0_21.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 issues at jboss.org  Wed Jan 29 04:13:28 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 29 Jan 2014 04:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is
 not writing data to store after removing from map in memory
In-Reply-To: <JIRA.12530574.1390986627000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530574.1390986627000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530574.1390986627000.19815.1390986808625@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek updated SECURITY-788:
----------------------------------

    Description: PicketBoxSecurityVault is not writing data to store after removing from map in memory.

    
> PicketBoxSecurityVault is not writing data to store after removing from map in memory
> -------------------------------------------------------------------------------------
>
>                 Key: SECURITY-788
>                 URL: https://issues.jboss.org/browse/SECURITY-788
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_20.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: PicketBox_4_0_21.Beta1
>
>
> PicketBoxSecurityVault is not writing data to store after removing from map in 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 issues at jboss.org  Wed Jan 29 04:17:28 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 29 Jan 2014 04:17:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is
 not writing data to store after removing from map in memory
In-Reply-To: <JIRA.12530574.1390986627000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530574.1390986627000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530574.1390986627000.19820.1390987048878@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek resolved SECURITY-788.
-----------------------------------

    Resolution: Done

    
> PicketBoxSecurityVault is not writing data to store after removing from map in memory
> -------------------------------------------------------------------------------------
>
>                 Key: SECURITY-788
>                 URL: https://issues.jboss.org/browse/SECURITY-788
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_20.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: PicketBox_4_0_21.Beta1
>
>
> PicketBoxSecurityVault is not writing data to store after removing from map in 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 issues at jboss.org  Wed Jan 29 04:23:29 2014
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 29 Jan 2014 04:23:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1777) TP: add more stats
In-Reply-To: <JIRA.12529847.1390217759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529847.1390217759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529847.1390217759000.19827.1390987409140@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1777.
----------------------------

    Resolution: Done


Added stats for
* num single msgs sent / received
* num batches sent / received
* avg batch sizes received
                
> TP: add more stats
> ------------------
>
>                 Key: JGRP-1777
>                 URL: https://issues.jboss.org/browse/JGRP-1777
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> * Number of single messages sent and received (oob, regular ?)
> * Number of bundles sent / batches received (oob, regular?)
> * Avg batch 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 issues at jboss.org  Wed Jan 29 04:27:29 2014
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 29 Jan 2014 04:27:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1158) add "remove vault entry"
 option to vault tool
In-Reply-To: <JIRA.12471159.1343221728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471159.1343221728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471159.1343221728000.19848.1390987649061@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939513#comment-12939513 ] 

Peter Skopek commented on WFLY-1158:
------------------------------------

I have branch ready for PR, just have to wait until new version of PicketBox (4.0.21.Beta1) will be released.
https://github.com/pskopek/wildfly/tree/vault-tool-remove-password
                
> add "remove vault entry" option to vault tool 
> ----------------------------------------------
>
>                 Key: WFLY-1158
>                 URL: https://issues.jboss.org/browse/WFLY-1158
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Gernot P
>            Assignee: Peter Skopek
>         Attachments: patch.diff
>
>
> You cannot remove an entry form vault with the vault tool. You can choose only amog following options "0: Store a password  1: Check whether password exists  2: Exit"
> Pleas add "remove password" option to vault tool (vault.sh)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 04:47:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Wed, 29 Jan 2014 04:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.19934.1390988848951@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939520#comment-12939520 ] 

Michal Babacek commented on WFLY-2591:
--------------------------------------

I can confirm this behaviour with WildFly *8.0.0.Final-SNAPSHOT*, my HEAD being {{2294aa91389bddc8f0a01acbc4aa6ee6cefe0fa0}}.

*Server one*, {{port-offset="$\{jboss.socket.binding.port-offset:0\}"}}, expected {{jboss.management.native.port}} is 9999
displays this message during startup:
{noformat}
INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 10.16.88.187:9999
{noformat}
An attempt to shut it down ends up with:
{noformat}
./jboss-cli.sh --connect --controller=10.16.88.187:9999 --command=:shutdown --timeout=10000
{"outcome" => "success"}
{noformat}

*Server two*, {{port-offset="$\{jboss.socket.binding.port-offset:101\}"}}, expected {{jboss.management.native.port}} is 10100
displays this message during startup:
{noformat}
INFO  [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 10.16.88.187:10100
{noformat}
An attempt to shut it down ends up with:
{noformat}
./jboss-cli.sh --connect --controller=10.16.88.187:10100 --command=:shutdown --timeout=10000
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
    at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:263)
    at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:226)
    at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.jboss.modules.Module.run(Module.java:292)
    at org.jboss.modules.Main.main(Main.java:455)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at 10.16.88.187:10100
    at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:990)
    at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:825)
    at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:811)
    at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:261)
    ... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://10.16.88.187:10100. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:967)
    ... 11 more
Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://10.16.88.187:10100. The connection failed
    at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
    at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
    at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
    at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
    at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
    at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
    at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
    at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
    ... 13 more
Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
    at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:298)
    at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:281)
    at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
    at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
    at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
    at org.xnio.nio.WorkerThread.run(WorkerThread.java:531)
    at ...asynchronous invocation...(Unknown Source)
    at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
    at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
    at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
    at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
    at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:79)
    at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:110)
    ... 23 more
{noformat}

The funny thing is that the process is actually listening on 10100:
{noformat}
[hudson at perf09 bin]$ netstat -an | grep 10100
tcp  0  0 10.16.88.187:10100  0.0.0.0:*           LISTEN    
tcp  0  0 10.16.88.187:10100  10.16.88.187:34448  TIME_WAIT 
{noformat}

If I kill the Server two process forcefully, port 10100 is released.
                
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 04:59:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Wed, 29 Jan 2014 04:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.19980.1390989568721@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939529#comment-12939529 ] 

Michal Babacek commented on WFLY-2591:
--------------------------------------

@[~dlofthouse]: Hello there, could you give us any update on this issue regarding its connection to [WFLY-1597] etc. ?
                
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 05:15:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 05:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1873) mod_cluster ISE on shutdown
In-Reply-To: <JIRA.12498516.1376424073000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498516.1376424073000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498516.1376424073000.20015.1390990529736@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-1873:
---------------------------------

    Priority: Blocker  (was: Major)


Michal is still able to reproduce this in master (jan 28?). Needs a fix. 
                
> mod_cluster ISE on shutdown
> ---------------------------
>
>                 Key: WFLY-1873
>                 URL: https://issues.jboss.org/browse/WFLY-1873
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> 16:45:28,305 ERROR [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (MSC service thread 1-2) Error [MEM: MEM: Can't read node: {4}] sending command DISABLE-APP to proxy localhost/127.0.0.1:6666, configuration will be reset
> 16:45:28,315 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow AJP listener ajp suspending
> 16:45:28,319 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 16:45:28,336 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010418: Stopped Driver service with driver-name = h2
> 16:45:28,344 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow HTTP listener default suspending
> 16:45:28,349 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 16:45:38,307 WARN  [org.jboss.modcluster.ModClusterService] (MSC service thread 1-2) Failed to drain pending requests from context [org.wildfly.mod_cluster.undertow.UndertowContext at 1906d941] within specified timeout: 10 seconds
> 16:45:38,308 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000004: Failure during stop of service jboss.undertow.deployment.default-host./clusterbench-ee6-web: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.onDeploymentStop(UndertowEventHandlerAdapter.java:137)
> 	at org.wildfly.extension.undertow.Host$2.invoke(Host.java:138)
> 	at org.wildfly.extension.undertow.UndertowService.fireEvent(UndertowService.java:168)
> 	at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:135)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:104)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2052) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2013) [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]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 05:49:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 29 Jan 2014 05:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.20089.1390992569487@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939544#comment-12939544 ] 

Stuart Douglas commented on WFLY-2778:
--------------------------------------

Did you manage to get some new stack traces with the upgraded XNIO in place?
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 06:23:28 2014
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Wed, 29 Jan 2014 06:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2827) Update to HAL 2.1.1.Final
In-Reply-To: <JIRA.12530605.1390994517755@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530605.1390994517755@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530605.1390994517755.20127.1390994608562@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2827:
---------------------------------

             Summary: Update to HAL 2.1.1.Final
                 Key: WFLY-2827
                 URL: https://issues.jboss.org/browse/WFLY-2827
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Harald Pehl
            Priority: Blocker
             Fix For: 8.0.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 issues at jboss.org  Wed Jan 29 06:41:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 29 Jan 2014 06:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.20180.1390995688791@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939564#comment-12939564 ] 

Darran Lofthouse commented on WFLY-2591:
----------------------------------------

Try: -

./jboss-cli.sh --connect --controller=remoting://10.16.88.187:10100 --command=:shutdown --timeout=10000
                
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 07:19:28 2014
From: issues at jboss.org (Jan Martiska (JIRA))
Date: Wed, 29 Jan 2014 07:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2760) Intermittent failure of
 ExternalContextBindingTestCase
In-Reply-To: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529570.1389865466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529570.1389865466000.20239.1390997968726@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Martiska resolved WFLY-2760.
--------------------------------

    Resolution: Done

    
>  Intermittent failure of ExternalContextBindingTestCase
> -------------------------------------------------------
>
>                 Key: WFLY-2760
>                 URL: https://issues.jboss.org/browse/WFLY-2760
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>            Priority: Minor
>
> The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.
> It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 07:31:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 07:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta]
 (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException"
 on reload
In-Reply-To: <JIRA.12530612.1390998643692@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530612.1390998643692@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530612.1390998643692.20249.1390998688748@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2828:
------------------------------------

             Summary: "WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
                 Key: WFLY-2828
                 URL: https://issues.jboss.org/browse/WFLY-2828
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Transactions
    Affects Versions: 8.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Tom Jenkinson


About 1/4 times.

{noformat}
13:26:27,786 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
13:26:27,787 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
13:26:27,861 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
13:26:27,874 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
13:26:27,875 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
13:26:27,877 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
13:26:27,894 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
13:26:27,895 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
13:26:27,897 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
13:26:27,897 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
13:26:27,897 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
13:26:27,900 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
13:26:27,900 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
13:26:27,901 WARN  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
13:26:27,901 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
13:26:27,901 INFO  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
13:26:27,901 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
13:26:27,904 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
13:26:27,906 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
13:26:27,915 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
	at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
	at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]

{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 issues at jboss.org  Wed Jan 29 07:31:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 07:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta]
 (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException"
 on reload
In-Reply-To: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530612.1390998643000.20252.1390998688983@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939574#comment-12939574 ] 

Radoslav Husar commented on WFLY-2828:
--------------------------------------

On master as of 2294aa91389bddc8f0a01acbc4aa6ee6cefe0fa0
                
> "WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2828
>                 URL: https://issues.jboss.org/browse/WFLY-2828
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Tom Jenkinson
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> 	at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {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 issues at jboss.org  Wed Jan 29 07:39:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 07:39:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2304) SESSION_DRAINING_STRATEGY is
 missing a validator and incorrectly uses setAlternatives()
In-Reply-To: <JIRA.12503066.1381830984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503066.1381830984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503066.1381830984000.20277.1390999169079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-2304.
--------------------------------



Merged.
                
> SESSION_DRAINING_STRATEGY is missing a validator and incorrectly uses setAlternatives()
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2304
>                 URL: https://issues.jboss.org/browse/WFLY-2304
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * this is wrong .setAlternatives("DEFAULT", "ALWAYS" , "NEVER")
> * add a proper validator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 08:07:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 29 Jan 2014 08:07:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2672) Additional debug logging for
 LDAP based group loading.
In-Reply-To: <JIRA.12528256.1387475787000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528256.1387475787000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528256.1387475787000.20362.1391000850155@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939588#comment-12939588 ] 

RH Bugzilla Integration commented on WFLY-2672:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1044772|https://bugzilla.redhat.com/show_bug.cgi?id=1044772] from ASSIGNED to POST
                
> Additional debug logging for LDAP based group loading.
> ------------------------------------------------------
>
>                 Key: WFLY-2672
>                 URL: https://issues.jboss.org/browse/WFLY-2672
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.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 issues at jboss.org  Wed Jan 29 08:45:29 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 29 Jan 2014 08:45:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2829) Optimistic locking w/write
 skew check requires versioning to be enabled
In-Reply-To: <JIRA.12530622.1391003086846@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530622.1391003086846@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530622.1391003086846.20607.1391003129433@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2829:
----------------------------------

             Summary: Optimistic locking w/write skew check requires versioning to be enabled
                 Key: WFLY-2829
                 URL: https://issues.jboss.org/browse/WFLY-2829
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Final


Without this, the user cannot configure OPTIMISTIC 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 issues at jboss.org  Wed Jan 29 08:49:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 29 Jan 2014 08:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2636) cli should be able to use the
 vault to encrypt a keystore password
In-Reply-To: <JIRA.12527656.1386765346000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527656.1386765346000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527656.1386765346000.20609.1391003368667@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2636.
-------------------------------------

    Resolution: Done


'ssl' element in jboss-cli.xml now has an optional child (first child in the sequence) element 'vault', which has a required attribute 'file', the value of which could be either an absolute or a relative path to the vault XML configuration file (the content of which is generated using vault.[sh|bat]).

'vault' element also has an optional attribute 'relative-to', which if present will indicate that the value of the required attribute 'file' should be used as a relative to the value of 'relative-to' path. The value of 'relative-to' can be one of the named system-provided paths such as: jboss.home.dir, user.home or user.dir.

The following elements in the ssl configuration support vault-encrypted values:
- key-store-password;
- key-password;
- trust-store-password.
                
> cli should be able to use the vault to encrypt a keystore password
> ------------------------------------------------------------------
>
>                 Key: WFLY-2636
>                 URL: https://issues.jboss.org/browse/WFLY-2636
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Kabir Khan
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> The CLI can be configured for two-way SSL to connect to the management interface. The password for keystore/truststore is currently limited to being plain text inside the "jboss-cli.xml" file.
> This request is to allow a CLI client to use a local vault to encrypt those password

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 08:51:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 08:51:29 -0500 (EST)
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.20618.1391003489511@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 resolved WFLY-1801.
-------------------------------

    Resolution: Done

    
> Allow remoting endpoint options to be configurable
> --------------------------------------------------
>
>                 Key: WFLY-1801
>                 URL: https://issues.jboss.org/browse/WFLY-1801
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>            Reporter: jaikiran pai
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Wed Jan 29 08:51:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 08:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-348) IO subsystem management API
In-Reply-To: <JIRA.12489434.1366010002000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489434.1366010002000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489434.1366010002000.20613.1391003489250@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-348.
------------------------------

    Resolution: Done

    
> IO subsystem management API
> ---------------------------
>
>                 Key: WFLY-348
>                 URL: https://issues.jboss.org/browse/WFLY-348
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Final
>
>
> Expose the IO subsystem management operations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 08:51:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 08:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2055) Centralize and organize
 I/O-related options into I/O subsystem
In-Reply-To: <JIRA.12500632.1379000746000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500632.1379000746000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500632.1379000746000.20626.1391003489883@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2055.
-------------------------------

    Resolution: Done


Done
                
> 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
>      Security Level: Public(Everyone can see) 
>          Components: Remoting, Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Wed Jan 29 08:53:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 08:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2729) Improve reporting when
 persistent session restore fails
In-Reply-To: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528911.1389217366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528911.1389217366000.20635.1391003609747@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2729:
------------------------------

          Summary: Improve reporting when persistent session restore fails  (was: Exception thrown, when you try to clean server)
       Issue Type: Enhancement  (was: Bug)
    Fix Version/s: 8.0.0.Final
                       (was: 8.0.0.CR1)
          Affects:   (was: Compatibility/Configuration)

    
> Improve reporting when persistent session restore fails
> -------------------------------------------------------
>
>                 Key: WFLY-2729
>                 URL: https://issues.jboss.org/browse/WFLY-2729
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Ubuntu Linux
>            Reporter: Paa Kojo Konduah Amos
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Final
>
>         Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws 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 issues at jboss.org  Wed Jan 29 08:53:30 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 29 Jan 2014 08:53:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2636) cli should be able to use the
 vault to encrypt a keystore password
In-Reply-To: <JIRA.12527656.1386765346000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527656.1386765346000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527656.1386765346000.20639.1391003610004@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2636:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5696, https://github.com/wildfly/wildfly/pull/5795

    
> cli should be able to use the vault to encrypt a keystore password
> ------------------------------------------------------------------
>
>                 Key: WFLY-2636
>                 URL: https://issues.jboss.org/browse/WFLY-2636
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>            Reporter: Kabir Khan
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> The CLI can be configured for two-way SSL to connect to the management interface. The password for keystore/truststore is currently limited to being plain text inside the "jboss-cli.xml" file.
> This request is to allow a CLI client to use a local vault to encrypt those password

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 08:57:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 29 Jan 2014 08:57:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.20676.1391003849306@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2591:
-----------------------------------

        Parent: WFLY-1597
    Issue Type: Sub-task  (was: Bug)

    
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 08:59:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 29 Jan 2014 08:59:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2496) Concurrent access to
 ModuleSpecification causes race condition
In-Reply-To: <JIRA.12524939.1384289082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524939.1384289082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524939.1384289082000.20685.1391003969389@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939657#comment-12939657 ] 

Stuart Douglas commented on WFLY-2496:
--------------------------------------

DUP's should not be adding dependencies to another deployments module spec. I think we should just fix the JSF one not to do this. 

                
> Concurrent access to ModuleSpecification causes race condition
> --------------------------------------------------------------
>
>                 Key: WFLY-2496
>                 URL: https://issues.jboss.org/browse/WFLY-2496
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> [ModuleSpecification|https://github.com/wildfly/wildfly/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecification.java] does not use any form of synchronization to protect its mutable state yet may be used from multiple threads in multi-module deployment when a DeploymentUnitProcessor touches ModuleSpecification of a different deployment unit which is processed at that moment.
> Here is an example of such access: https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFDependencyProcessor.java#L93
> Here's how I think this problem manifests:
> {noformat}
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:284) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:220) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:125) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:88) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         ... 5 more
> {noformat}
> and here's my attempt to verify concurrent access by changing the code slightly to deadlock on concurrent access: 
> {noformat}
> "MSC service thread 1-6":
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x00000000f742ba28> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:170)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
>         - locked <0x00000000f69a8e88> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:744)
> "MSC service thread 1-3":
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x00000000f742ba58> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:175)
>         at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
>         at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
>         - locked <0x00000000f6782960> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:744)
> {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 issues at jboss.org  Wed Jan 29 09:03:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Wed, 29 Jan 2014 09:03:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.20693.1391004208829@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939708#comment-12939708 ] 

Michal Babacek commented on WFLY-2591:
--------------------------------------

@[~dlofthouse]: THX, it works like a charm :-)

                
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 09:03:29 2014
From: issues at jboss.org (Ales Justin (JIRA))
Date: Wed, 29 Jan 2014 09:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2829) Optimistic locking w/write
 skew check requires versioning to be enabled
In-Reply-To: <JIRA.12530622.1391003086000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530622.1391003086000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530622.1391003086000.20698.1391004209086@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated WFLY-2829:
------------------------------

    Priority: Blocker  (was: Major)

    
> Optimistic locking w/write skew check requires versioning to be enabled
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2829
>                 URL: https://issues.jboss.org/browse/WFLY-2829
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Without this, the user cannot configure OPTIMISTIC 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 issues at jboss.org  Wed Jan 29 09:05:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 29 Jan 2014 09:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2591) CLI can not connect to the
 server started with port-offset
In-Reply-To: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526571.1385821765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526571.1385821765000.20705.1391004329459@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2591.
------------------------------------

    Resolution: Duplicate Issue

    
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
>                 Key: WFLY-2591
>                 URL: https://issues.jboss.org/browse/WFLY-2591
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1, 8.0.0.Final
>         Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date:   Wed Nov 20 17:05:00 2013 +0100
>            Reporter: Wolf-Dieter Fink
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
>   bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
>   bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection 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 org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> 	at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> 	at ...asynchronous invocation...(Unknown Source)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> 	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> 	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> 	... 23 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 issues at jboss.org  Wed Jan 29 09:07:29 2014
From: issues at jboss.org (Ales Justin (JIRA))
Date: Wed, 29 Jan 2014 09:07:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2830) Fix
 org.infinispan.lucene.directory dependencies
In-Reply-To: <JIRA.12530628.1391004400211@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530628.1391004400211@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530628.1391004400211.20713.1391004449396@jira02.app.mwc.hst.phx2.redhat.com>

Ales Justin created WFLY-2830:
---------------------------------

             Summary: Fix org.infinispan.lucene.directory dependencies
                 Key: WFLY-2830
                 URL: https://issues.jboss.org/browse/WFLY-2830
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Ales Justin
            Assignee: Paul Ferraro
            Priority: Blocker
             Fix For: 8.0.0.Final


The module is missing a bunch of dependencies,
proper module.xml looks like this: https://gist.github.com/alesj/8688428

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:11:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 09:11:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2289) deployed webapp before
 mod_cluster httpd discovery aren't see by httpd.
In-Reply-To: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502817.1381495589000.20728.1391004689060@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939709#comment-12939709 ] 

Radoslav Husar commented on WFLY-2289:
--------------------------------------

I cannot reproduce the bug :-(
                
> deployed webapp before mod_cluster httpd discovery aren't see by httpd.
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2289
>                 URL: https://issues.jboss.org/browse/WFLY-2289
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:23:28 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 29 Jan 2014 09:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2830) Fix
 org.infinispan.lucene.directory dependencies
In-Reply-To: <JIRA.12530628.1391004400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530628.1391004400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530628.1391004400000.20741.1391005408870@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2830:
-------------------------------

    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/5808)

    
> Fix org.infinispan.lucene.directory dependencies
> ------------------------------------------------
>
>                 Key: WFLY-2830
>                 URL: https://issues.jboss.org/browse/WFLY-2830
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ales Justin
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> The module is missing a bunch of dependencies,
> proper module.xml looks like this: https://gist.github.com/alesj/8688428

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:25:28 2014
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 29 Jan 2014 09:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2830) Fix
 org.infinispan.lucene.directory dependencies
In-Reply-To: <JIRA.12530628.1391004400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530628.1391004400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530628.1391004400000.20746.1391005528786@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2830:
-------------------------------

    Assignee: Sanne Grinovero  (was: Paul Ferraro)

    
> Fix org.infinispan.lucene.directory dependencies
> ------------------------------------------------
>
>                 Key: WFLY-2830
>                 URL: https://issues.jboss.org/browse/WFLY-2830
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Ales Justin
>            Assignee: Sanne Grinovero
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> The module is missing a bunch of dependencies,
> proper module.xml looks like this: https://gist.github.com/alesj/8688428

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:49:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 29 Jan 2014 09:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2745) Typo in jboss-cli help message
In-Reply-To: <JIRA.12529155.1389563386000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529155.1389563386000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529155.1389563386000.20836.1391006968817@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2745:
------------------------------------

       Fix Version/s: 8.0.1.Final
    Git Pull Request: https://github.com/wildfly/wildfly/pull/5810

    
> Typo in jboss-cli help message
> ------------------------------
>
>                 Key: WFLY-2745
>                 URL: https://issues.jboss.org/browse/WFLY-2745
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Arun Gupta
>            Assignee: Alexey Loubyansky
>            Priority: Trivial
>             Fix For: 8.0.1.Final
>
>
> jboss-cli -h shows the following help message for --controller.
> The default controller host is localhost and the port is 9999.
> The port number should be 9990 instead of 9999.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:51:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 29 Jan 2014 09:51:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2745) Typo in jboss-cli help message
In-Reply-To: <JIRA.12529155.1389563386000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529155.1389563386000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529155.1389563386000.20851.1391007088915@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2745:
------------------------------------

    Fix Version/s: 8.0.0.Final
                       (was: 8.0.1.Final)

    
> Typo in jboss-cli help message
> ------------------------------
>
>                 Key: WFLY-2745
>                 URL: https://issues.jboss.org/browse/WFLY-2745
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Arun Gupta
>            Assignee: Alexey Loubyansky
>            Priority: Trivial
>             Fix For: 8.0.0.Final
>
>
> jboss-cli -h shows the following help message for --controller.
> The default controller host is localhost and the port is 9999.
> The port number should be 9990 instead of 9999.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:53:30 2014
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 29 Jan 2014 09:53:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2831) Method
 Utils.getSecondaryTestAddress(ManagementClient,
 boolean) doesn't strip square brackets from host IPv6 address
In-Reply-To: <JIRA.12530640.1391007201635@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530640.1391007201635@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530640.1391007201635.20874.1391007210135@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2831:
---------------------------------

             Summary: Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address
                 Key: WFLY-2831
                 URL: https://issues.jboss.org/browse/WFLY-2831
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Josef Cacek
            Assignee: Josef Cacek


The striping of square brackets around IPv6 addresses doesn't work in 
org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 09:55:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 29 Jan 2014 09:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2831) Method
 Utils.getSecondaryTestAddress(ManagementClient,
 boolean) doesn't strip square brackets from host IPv6 address
In-Reply-To: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530640.1391007201000.20876.1391007328582@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2831:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059260

    
> Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2831
>                 URL: https://issues.jboss.org/browse/WFLY-2831
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The striping of square brackets around IPv6 addresses doesn't work in 
> org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:09:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 29 Jan 2014 10:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2831) Method
 Utils.getSecondaryTestAddress(ManagementClient,
 boolean) doesn't strip square brackets from host IPv6 address
In-Reply-To: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530640.1391007201000.20940.1391008168636@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939746#comment-12939746 ] 

RH Bugzilla Integration commented on WFLY-2831:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> changed the Status of [bug 1059260|https://bugzilla.redhat.com/show_bug.cgi?id=1059260] from NEW to POST
                
> Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2831
>                 URL: https://issues.jboss.org/browse/WFLY-2831
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The striping of square brackets around IPv6 addresses doesn't work in 
> org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:11:28 2014
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 29 Jan 2014 10:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2831) Method
 Utils.getSecondaryTestAddress(ManagementClient,
 boolean) doesn't strip square brackets from host IPv6 address
In-Reply-To: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530640.1391007201000.20948.1391008288813@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-2831:
------------------------------

    Bugzilla Update:   (was: Perform)

    
> Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2831
>                 URL: https://issues.jboss.org/browse/WFLY-2831
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The striping of square brackets around IPv6 addresses doesn't work in 
> org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:13:28 2014
From: issues at jboss.org (mary pablate (JIRA))
Date: Wed, 29 Jan 2014 10:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-18) Problem when path
 containing the project is too long
In-Reply-To: <JIRA.12317814.1125423158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12317814.1125423158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12317814.1125423158000.20955.1391008408724@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/HIBERNATE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939750#comment-12939750 ] 

mary pablate commented on HIBERNATE-18:
---------------------------------------

Well, you can use Long Path Tool for such issues, it works good.
                
> Problem when path containing the project is too long
> ----------------------------------------------------
>
>                 Key: HIBERNATE-18
>                 URL: https://issues.jboss.org/browse/HIBERNATE-18
>             Project: Hibernate Integration
>          Issue Type: Bug
>         Environment: Eclipse 3.1
> Embeddable EJB 3.0
> Example: microcontainer-deployment
>            Reporter: Doink06 Doink06
>            Assignee: Gavin King
>
> Hello,
> I have the following configuration:
> - an eclipse workspace, which contains all the examples extrated from "Embeddable EJB 3.0"
> - Each example is transformed into a java project
> - a special project named Jboss is containing Embeddable EJB 3.0 with subdirectories lib/ and conf/
> Case #1
> The workspace is located on my disk at the following place : "D:/EJB3Examples"
> The example microcontainer-deployment is working perfectly
> Case #2
> I moved the workspace to the following place : "D:/Projects/Java/Eclipse3/EJB3Examples"
> The example microcontainer-deployment is crashing.
> WARN  30-08 01:02:38,906 (JBossEntityResolver.java:getLocalEntityName:201)  -Entity is not registered, publicId=null systemId=file:/D:/Projects/Java/Eclipse3/EJB3Examples/jboss/conf/bean-deployer_1_0.xsd
> WARN  30-08 01:02:38,953 (SaxJBossXBParser.java:warning:226)  -schema_reference.4: Failed to read schema document 'bean-deployer_1_0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. @ file:/D:/Projects/Java/Eclipse3/EJB3Examples/jboss/conf/embedded-jboss-beans.xml[5,45]
> WARN  30-08 01:02:41,062 (JBossEntityResolver.java:getLocalEntityName:201)  -Entity is not registered, publicId=null systemId=file:/D:/Projects/Java/Eclipse3/EJB3Examples/microcontainer-deployment/conf/bean-deployer_1_0.xsd
> WARN  30-08 01:02:41,062 (SaxJBossXBParser.java:warning:226)  -schema_reference.4: Failed to read schema document 'bean-deployer_1_0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. @ file:/D:/Projects/Java/Eclipse3/EJB3Examples/microcontainer-deployment/conf/ejb3-deployment.xml[5,45]
> ERROR 30-08 01:02:45,609 (EjbTimerUtil.java:getTimerService:43)  -Unable to initialize timer service
> ----------------------------------------------------------
> Exception in thread "main" javax.ejb.EJBException: null; CausedByException is:
> 	Unknown entity: org.jboss.tutorial.mcdeploy.Customer
> 	at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:46)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:70)
> 	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:134)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:152)
> 	at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60)
> 	at $Proxy11.createCustomer(Unknown Source)
> 	at org.jboss.tutorial.mcdeploy.Main.main(Main.java:32)
> java.lang.IllegalArgumentException: Unknown entity: org.jboss.tutorial.mcdeploy.Customer
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:133)
> 	at org.jboss.ejb3.entity.InjectedEntityManager.persist(InjectedEntityManager.java:97)
> 	at org.jboss.tutorial.mcdeploy.CustomerDAOBean.createCustomer(CustomerDAOBean.java:28)
> 	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:585)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:32)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:134)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:61)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:39)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:63)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:91)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:91)
> 	at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:152)
> 	at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:60)
> 	at $Proxy11.createCustomer(Unknown Source)
> 	at org.jboss.tutorial.mcdeploy.Main.main(Main.java:32)
> Case #3
> I have copied the workspace to the following directory "D:\Projects\EJB3Examples"
> It works fine
> Case #4
> I have copied the workspace to the following directory "D:\Projects\Java\EJB3Examples"
> It works fine
> Case #5
> I have copied the workspace to the following directory "D:\Projects\Java\Eclips3\EJB3Examples"
> Without the "e" for eclips3. It works fine
> Case #5
> As soon as I rename the directory Eclips3 into Eclipse3, it crashes ... ?!?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:35:33 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 10:35:33 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.21053.1391009733584@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939766#comment-12939766 ] 

Brad Maxwell commented on WFLY-2198:
------------------------------------

Resolved in jboss-remote-naming 2.0.0.Final and 1.0.8.Final
                
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:39:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 29 Jan 2014 10:39:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.21067.1391009969483@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------

            Assignee: Jason Greene  (was: Aleksandar Kostadinov)
    Git Pull Request: https://github.com/wildfly/wildfly/pull/5813


I'm adding a pull request. As far as I could test, the change fixes the problem on reload when IP and reverse DNS entry do not match.

There was also another problem to this that affected the test suite. Remoting also did a reverse lookup but it is a separate issue and I filed a PR for it as well (REM3-180). Hopefully wildfly will pick it from remoting 4.1.0. So in summary to get a good test run on windows with IPs without reverse DNS entries, one needs to use patched remoting in addition. There is no problem to run the TS on IPs with valid records with either change.
                
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Jason Greene
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:39:29 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 29 Jan 2014 10:39:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.21073.1391009969867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------

    Comment: was deleted

(was: This change seems to break test suite for wildfly, it was good for EAP. I'll have to find out the cause of this.)

    
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Jason Greene
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:39:30 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 29 Jan 2014 10:39:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.21076.1391009970029@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov updated WFLY-2785:
----------------------------------------

    Comment: was deleted

(was: want to run a few tests before I file a PR)

    
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Jason Greene
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:41:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 29 Jan 2014 10:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.21086.1391010088906@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov reassigned WFLY-2785:
-------------------------------------------

    Assignee: Emanuel Muckenhuber  (was: Jason Greene)


Emanuel, could you please take a look at this change?
                
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Emanuel Muckenhuber
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 10:49:28 2014
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Wed, 29 Jan 2014 10:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2832) Component upgrade to
 Hibernate Search 4.5.0.Final
In-Reply-To: <JIRA.12530648.1391010456303@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530648.1391010456303@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530648.1391010456303.21106.1391010568556@jira02.app.mwc.hst.phx2.redhat.com>

Sanne Grinovero created WFLY-2832:
-------------------------------------

             Summary: Component upgrade to Hibernate Search 4.5.0.Final
                 Key: WFLY-2832
                 URL: https://issues.jboss.org/browse/WFLY-2832
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, JPA / Hibernate
            Reporter: Sanne Grinovero
            Assignee: Sanne Grinovero
             Fix For: 8.0.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 issues at jboss.org  Wed Jan 29 10:59:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 29 Jan 2014 10:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2782) Testsuite leaks remoting
 endpoints by not closing JMXConnector
In-Reply-To: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529906.1390245829000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529906.1390245829000.21145.1391011168630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939780#comment-12939780 ] 

RH Bugzilla Integration commented on WFLY-2782:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1055912|https://bugzilla.redhat.com/show_bug.cgi?id=1055912] from ON_QA to VERIFIED
                
> Testsuite leaks remoting endpoints by not closing JMXConnector
> --------------------------------------------------------------
>
>                 Key: WFLY-2782
>                 URL: https://issues.jboss.org/browse/WFLY-2782
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Whereever JMXConnectorFactory.connect() is called, the resulting JMXConnector should be closed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 11:05:28 2014
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 29 Jan 2014 11:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2833) data-source:enalbe and
 datasource:write-attribute(name=enabled, value=true) should have same result
In-Reply-To: <JIRA.12530655.1391011485008@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530655.1391011485008@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530655.1391011485008.21160.1391011528804@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-2833:
-------------------------------------

             Summary: data-source:enalbe and datasource:write-attribute(name=enabled, value=true) should have same result
                 Key: WFLY-2833
                 URL: https://issues.jboss.org/browse/WFLY-2833
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.CR1
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri


Currently enabled attribute always require a reload, while it should provide same functionalyity of :enable (and symmetric :disable operation) enabling/disabling datasource runtime.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 11:35:29 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Wed, 29 Jan 2014 11:35:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.21217.1391013329303@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939801#comment-12939801 ] 

Nedo Nedic commented on DROOLS-418:
-----------------------------------

I tried it with 5.6.0 Final and it fails with same exception.
                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 11:41:29 2014
From: issues at jboss.org (Matthias Richter (JIRA))
Date: Wed, 29 Jan 2014 11:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.21243.1391013689702@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939803#comment-12939803 ] 

Matthias Richter commented on WFLY-2778:
----------------------------------------

Well, up until now we cannot see the issue again, seems to be working!

We'll keep the instance running and observe its behavior. Thanks for your work, guys.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 11:51:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 11:51:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2778) CPU load at 99% with WildFly
	8 CR1
In-Reply-To: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529838.1390214792000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529838.1390214792000.21270.1391014289405@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2778.
-------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done


Tnx Matthias for confirming that it works now.
                
> CPU load at 99% with WildFly 8 CR1
> ----------------------------------
>
>                 Key: WFLY-2778
>                 URL: https://issues.jboss.org/browse/WFLY-2778
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: $ java -version
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> WildFly 8.0.0.CR1
> XNIO version 3.2.0.Beta4
> Undertow 1.0.0.Beta30
>            Reporter: Matthias Richter
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>         Attachments: stacktrace-6156.out, stacktrace-6157.out, stacktrace-6158.out, stacktrace-new.out
>
>
> After Undertow included https forwarding features when shipped with Wildfly CR1, we experienced high cpu load on our machines, reproduced on 5 different servers. Up to 3 threads are running wild, sometimes it's just one thread though. On the forum reference there are screenshots from jconsole including stacktraces of the threads.
> https://community.jboss.org/message/853569#853569

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 12:27:30 2014
From: issues at jboss.org (Jean-Frederic Clere (JIRA))
Date: Wed, 29 Jan 2014 12:27:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2289) deployed webapp before
 mod_cluster httpd discovery aren't see by httpd.
In-Reply-To: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502817.1381495589000.21351.1391016450284@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Frederic Clere resolved WFLY-2289.
---------------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done


It looks fixed now.
                
> deployed webapp before mod_cluster httpd discovery aren't see by httpd.
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2289
>                 URL: https://issues.jboss.org/browse/WFLY-2289
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>             Fix For: 8.0.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 issues at jboss.org  Wed Jan 29 12:41:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 29 Jan 2014 12:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2490) Connecting using
 https-remoting times out and leaves thread within CLI spinning at 100%
In-Reply-To: <JIRA.12524819.1384192055000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524819.1384192055000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524819.1384192055000.21373.1391017289612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2490.
------------------------------------

    Resolution: Done


With the most recent XNIO update this is no longer an issue.
                
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2490
>                 URL: https://issues.jboss.org/browse/WFLY-2490
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: CLI, Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 13:07:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 29 Jan 2014 13:07:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2834) Remove
 'org.jboss.as.domain.management.security.util.MSCTestRunner' class.
In-Reply-To: <JIRA.12530668.1391018776003@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530668.1391018776003@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530668.1391018776003.21408.1391018848696@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2834:
--------------------------------------

             Summary: Remove 'org.jboss.as.domain.management.security.util.MSCTestRunner' class.
                 Key: WFLY-2834
                 URL: https://issues.jboss.org/browse/WFLY-2834
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, Test Suite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Final


The class 'org.jboss.as.domain.management.security.util.MSCTestRunner' was never actually used so should not have been committed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 13:53:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 13:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2835) Session draining broken:
 requests counting broken on load-balancer
In-Reply-To: <JIRA.12530673.1391021607611@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530673.1391021607611@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530673.1391021607611.21450.1391021609185@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2835:
------------------------------------

             Summary: Session draining broken: requests counting broken on load-balancer
                 Key: WFLY-2835
                 URL: https://issues.jboss.org/browse/WFLY-2835
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


See all details at MODCLUSTER-383.

Tracker bug, so that this gets into the realease notes as known issue if it doesn't get fixed for 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 issues at jboss.org  Wed Jan 29 13:57:28 2014
From: issues at jboss.org (dfisher (JIRA))
Date: Wed, 29 Jan 2014 13:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2836) http-listener requires
 'https' socket-binding
In-Reply-To: <JIRA.12530674.1391021790582@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530674.1391021790582@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530674.1391021790582.21474.1391021848899@jira02.app.mwc.hst.phx2.redhat.com>

dfisher created WFLY-2836:
-----------------------------

             Summary: http-listener requires 'https' socket-binding
                 Key: WFLY-2836
                 URL: https://issues.jboss.org/browse/WFLY-2836
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1, 8.0.0.Final
            Reporter: dfisher
            Assignee: Stuart Douglas
            Priority: Minor


Using a http-listener without the redirect-socket attribute requires the configuration to define a socket-binding with name "https".

The following error is produced attempting to configure wildfly without https:
{code}
ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
    ("subsystem" => "undertow"),
    ("server" => "default-server"),
    ("http-listener" => "default")
]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
{code}

I believe this constant is defined in ListenerResourceDefinition on line 80.

If this is the desired behavior, the undertow schema should probably be updated to make redirect-socket required or at least document the dependency.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 13:59:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 13:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2837) "UT015005: Error invoking
 method requestDestroyed on listener class ..." on clean shutdown with
 session draining
In-Reply-To: <JIRA.12530676.1391021894340@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530676.1391021894340@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530676.1391021894340.21480.1391021968622@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2837:
------------------------------------

             Summary: "UT015005: Error invoking method requestDestroyed on listener class ..." on clean shutdown with session draining
                 Key: WFLY-2837
                 URL: https://issues.jboss.org/browse/WFLY-2837
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Stuart Douglas


When using mod_cluster session draining and shutting down, draining for 10 seconds results in problem with invoking requestDestroyed listener event.

Seems to me like dependency orchestration problem on shutdown..

{noformat}
19:01:31,978 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar) in 437ms
19:01:31,978 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT.war) in 462ms
19:01:31,981 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 441ms
19:01:35,505 INFO  [org.jboss.test.clusterbench.web.load.AverageSystemLoadServlet] (default task-2) DONE, I was stressing CPU with 4 evil threads for 5027 milliseconds (including warm-up).
19:01:35,510 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: java.lang.RuntimeException: javax.servlet.ServletException: UT010013: Could not instantiate com.sun.faces.config.ConfigureListener
	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:77) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:297) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:685) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: javax.servlet.ServletException: UT010013: Could not instantiate com.sun.faces.config.ConfigureListener
	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:50) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:75) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	... 11 more
Caused by: java.lang.IllegalStateException
	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:97)
	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:41)
	at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1132)
	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:48) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	... 12 more

19:01:35,513 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.RuntimeException: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.servlet.WeldInitialListener
	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:77) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:297) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:685) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.servlet.WeldInitialListener
	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:50) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:75) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	... 11 more
Caused by: java.lang.IllegalStateException
	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:97)
	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:41)
	at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1132)
	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:48) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
	... 12 more

19:01:41,578 INFO  [org.jboss.modcluster] (MSC service thread 1-6) MODCLUSTER000021: All pending requests drained from default-host:/clusterbench in 10.0 seconds
19:01:41,580 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 60) MODCLUSTER000002: Initiating mod_cluster shutdown
19:01:41,580 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017521: Undertow AJP listener ajp suspending
19:01:41,582 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
19:01:41,583 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017506: Undertow 1.0.0.Beta33 stopping
19:01:41,586 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 10026ms
{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 issues at jboss.org  Wed Jan 29 14:05:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 14:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2836) http-listener requires
 'https' socket-binding
In-Reply-To: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530674.1391021790000.21508.1391022328806@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2836:
---------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> http-listener requires 'https' socket-binding
> ---------------------------------------------
>
>                 Key: WFLY-2836
>                 URL: https://issues.jboss.org/browse/WFLY-2836
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1, 8.0.0.Final
>            Reporter: dfisher
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> Using a http-listener without the redirect-socket attribute requires the configuration to define a socket-binding with name "https".
> The following error is produced attempting to configure wildfly without https:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "undertow"),
>     ("server" => "default-server"),
>     ("http-listener" => "default")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
> {code}
> I believe this constant is defined in ListenerResourceDefinition on line 80.
> If this is the desired behavior, the undertow schema should probably be updated to make redirect-socket required or at least document the dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 14:05:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 14:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2836) http-listener requires
 'https' socket-binding
In-Reply-To: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530674.1391021790000.21511.1391022328999@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2836:
------------------------------

    Fix Version/s: 8.0.0.Final

    
> http-listener requires 'https' socket-binding
> ---------------------------------------------
>
>                 Key: WFLY-2836
>                 URL: https://issues.jboss.org/browse/WFLY-2836
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1, 8.0.0.Final
>            Reporter: dfisher
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Using a http-listener without the redirect-socket attribute requires the configuration to define a socket-binding with name "https".
> The following error is produced attempting to configure wildfly without https:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "undertow"),
>     ("server" => "default-server"),
>     ("http-listener" => "default")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
> {code}
> I believe this constant is defined in ListenerResourceDefinition on line 80.
> If this is the desired behavior, the undertow schema should probably be updated to make redirect-socket required or at least document the dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 14:05:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 14:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2836) http-listener requires
 'https' socket-binding
In-Reply-To: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530674.1391021790000.21515.1391022329639@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2836:
------------------------------

    Affects Version/s:     (was: 8.0.0.Final)

    
> http-listener requires 'https' socket-binding
> ---------------------------------------------
>
>                 Key: WFLY-2836
>                 URL: https://issues.jboss.org/browse/WFLY-2836
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: dfisher
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Using a http-listener without the redirect-socket attribute requires the configuration to define a socket-binding with name "https".
> The following error is produced attempting to configure wildfly without https:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "undertow"),
>     ("server" => "default-server"),
>     ("http-listener" => "default")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
> {code}
> I believe this constant is defined in ListenerResourceDefinition on line 80.
> If this is the desired behavior, the undertow schema should probably be updated to make redirect-socket required or at least document the dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 14:11:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 29 Jan 2014 14:11:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2836) http-listener requires
 'https' socket-binding
In-Reply-To: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530674.1391021790000.21538.1391022689927@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939850#comment-12939850 ] 

Tomaz Cerar commented on WFLY-2836:
-----------------------------------

In default configs we ship https socket binding, to help with exactly this kind of things...
you didn't start with provided configuration files?
                
> http-listener requires 'https' socket-binding
> ---------------------------------------------
>
>                 Key: WFLY-2836
>                 URL: https://issues.jboss.org/browse/WFLY-2836
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: dfisher
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Using a http-listener without the redirect-socket attribute requires the configuration to define a socket-binding with name "https".
> The following error is produced attempting to configure wildfly without https:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "undertow"),
>     ("server" => "default-server"),
>     ("http-listener" => "default")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
> {code}
> I believe this constant is defined in ListenerResourceDefinition on line 80.
> If this is the desired behavior, the undertow schema should probably be updated to make redirect-socket required or at least document the dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 14:41:28 2014
From: issues at jboss.org (Christopher Klein (JIRA))
Date: Wed, 29 Jan 2014 14:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.21623.1391024488952@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939865#comment-12939865 ] 

Christopher Klein commented on WFLY-2816:
-----------------------------------------

I put a message on the mailing list. Let's see what the reactions are.
                
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 14:47:28 2014
From: issues at jboss.org (dfisher (JIRA))
Date: Wed, 29 Jan 2014 14:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2836) http-listener requires
 'https' socket-binding
In-Reply-To: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530674.1391021790000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530674.1391021790000.21631.1391024848653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939868#comment-12939868 ] 

dfisher commented on WFLY-2836:
-------------------------------

I need multiple http-listeners, so I renamed the listeners and the socket-bindings in the default config to be representative of their purpose in our environment.
That's how I discovered this dependency on a socket-binding named 'https'.

                
> http-listener requires 'https' socket-binding
> ---------------------------------------------
>
>                 Key: WFLY-2836
>                 URL: https://issues.jboss.org/browse/WFLY-2836
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: dfisher
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Using a http-listener without the redirect-socket attribute requires the configuration to define a socket-binding with name "https".
> The following error is produced attempting to configure wildfly without https:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "undertow"),
>     ("server" => "default-server"),
>     ("http-listener" => "default")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.default is missing [jboss.binding.https]"]}
> {code}
> I believe this constant is defined in ListenerResourceDefinition on line 80.
> If this is the desired behavior, the undertow schema should probably be updated to make redirect-socket required or at least document the dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 15:57:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 29 Jan 2014 15:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2838) Revisit default mod_cluster
 metric for WildFly 8
In-Reply-To: <JIRA.12530685.1391028993119@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530685.1391028993119@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530685.1391028993119.21719.1391029048532@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2838:
------------------------------------

             Summary: Revisit default mod_cluster metric for WildFly 8
                 Key: WFLY-2838
                 URL: https://issues.jboss.org/browse/WFLY-2838
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Blocker
             Fix For: 8.0.0.Final


Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.

Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.

Metric "cpu" is also a good candidate since it doesn't need explicit capacity.. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 16:11:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 16:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853134@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853134@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853134.21736.1391029888587@jira02.app.mwc.hst.phx2.redhat.com>

Brad Maxwell created WFLY-2839:
----------------------------------

             Summary: Remote Naming communication exception should be thrown on ConnectException
                 Key: WFLY-2839
                 URL: https://issues.jboss.org/browse/WFLY-2839
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: 8.0.0.CR1
            Reporter: Brad Maxwell
            Assignee: Brad Maxwell


Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 16:11:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 16:11:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.21738.1391029888624@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-2839:
-------------------------------


    
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 16:35:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 29 Jan 2014 16:35:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2816) Favour jboss-persistence.xml
	if present
In-Reply-To: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530354.1390746913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530354.1390746913000.21774.1391031328859@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2816:
-------------------------------

    Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001522.html

    
> Favour jboss-persistence.xml if present
> ---------------------------------------
>
>                 Key: WFLY-2816
>                 URL: https://issues.jboss.org/browse/WFLY-2816
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate, Server
>            Reporter: Christopher Klein
>            Assignee: Scott Marlow
>            Priority: Minor
>
> For developing for different target application servers (e.g. JBoss and WebSphere) it would be nice if WildFly favours a jboss-persistence.xml instead of the original persistence.xml.
> The jboss-persistence.xml is specific for the deployment inside WildFly, the persistence.xml would be the fallback/default for other application servers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 16:59:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Wed, 29 Jan 2014 16:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad
	passwords
In-Reply-To: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503730.1381946649000.21786.1391032768676@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939902#comment-12939902 ] 

Jason Greene commented on WFLY-2322:
------------------------------------

actually whats wrong me with. Why do we want to reject bad passwords by default. Isn't a warning enough?
                
> Update add-user to REJECT bad passwords
> ---------------------------------------
>
>                 Key: WFLY-2322
>                 URL: https://issues.jboss.org/browse/WFLY-2322
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 16:59:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Wed, 29 Jan 2014 16:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad
	passwords
In-Reply-To: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503730.1381946649000.21788.1391032768811@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939903#comment-12939903 ] 

Jason Greene commented on WFLY-2322:
------------------------------------

btw sorry that i did not correctly parse the subject of this issue and you put in the work
                
> Update add-user to REJECT bad passwords
> ---------------------------------------
>
>                 Key: WFLY-2322
>                 URL: https://issues.jboss.org/browse/WFLY-2322
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 17:21:28 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 29 Jan 2014 17:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2819) Cherry-pick Mojarra fix for
 ClassPathException when custom VisitContextFactory is used
In-Reply-To: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530431.1390845136000.21797.1391034088709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-2819:
-----------------------------

    Affects Version/s: 8.0.0.CR1
                           (was: 8.0.0.Final)

    
> Cherry-pick Mojarra fix for ClassPathException when custom VisitContextFactory is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2819
>                 URL: https://issues.jboss.org/browse/WFLY-2819
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Luk?? Fry?
>            Assignee: Farah Juma
>
> See https://java.net/jira/browse/JAVASERVERFACES-3156
> This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.
> See also related update: WFLY-2796

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Jan 29 17:21:28 2014
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 29 Jan 2014 17:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2819) Cherry-pick Mojarra fix for
 ClassPathException when custom VisitContextFactory is used
In-Reply-To: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530431.1390845136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530431.1390845136000.21799.1391034088807@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-2819:
-----------------------------

    Fix Version/s: 8.0.0.Final

    
> Cherry-pick Mojarra fix for ClassPathException when custom VisitContextFactory is used
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2819
>                 URL: https://issues.jboss.org/browse/WFLY-2819
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Luk?? Fry?
>            Assignee: Farah Juma
>             Fix For: 8.0.0.Final
>
>
> See https://java.net/jira/browse/JAVASERVERFACES-3156
> This fix allows to leverage VisitContextFactory/Wrapper features properly and enables RF-13505.
> See also related update: WFLY-2796

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Wed Jan 29 19:29:28 2014
From: issues at jboss.org (Tom Wells (JIRA))
Date: Wed, 29 Jan 2014 19:29:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2694) CLI example output for
 connecting to domain controller inaccurate
In-Reply-To: <JIRA.12528461.1388434483000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528461.1388434483000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528461.1388434483000.21936.1391041768826@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Wells resolved WFLY-2694.
-----------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done


Corrected the CLI output documented in the following section:

https://docs.jboss.org/author/display/WFLY8/Management+Clients
                
> CLI example output for connecting to domain controller inaccurate
> -----------------------------------------------------------------
>
>                 Key: WFLY-2694
>                 URL: https://issues.jboss.org/browse/WFLY-2694
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 8.0.0.CR1
>         Environment: Raspberry Pi
> Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
>            Reporter: Mark Little
>            Assignee: Tom Wells
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> According to https://docs.jboss.org/author/display/WFLY8/Management+Clients
> ---
> ./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 /]
>  
> [disconnected /] connect
> Connected to domain controller at localhost:9999
> ----
> But no "Connected to domain controller" is output. No indication of success is given other than the next line of the CLI has the hostname (localhost) referenced.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 19:29:29 2014
From: issues at jboss.org (Tom Wells (JIRA))
Date: Wed, 29 Jan 2014 19:29:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2694) CLI example output for
 connecting to domain controller inaccurate
In-Reply-To: <JIRA.12528461.1388434483000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528461.1388434483000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528461.1388434483000.21939.1391041769066@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Wells closed WFLY-2694.
---------------------------


    
> CLI example output for connecting to domain controller inaccurate
> -----------------------------------------------------------------
>
>                 Key: WFLY-2694
>                 URL: https://issues.jboss.org/browse/WFLY-2694
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 8.0.0.CR1
>         Environment: Raspberry Pi
> Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
>            Reporter: Mark Little
>            Assignee: Tom Wells
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> According to https://docs.jboss.org/author/display/WFLY8/Management+Clients
> ---
> ./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 /]
>  
> [disconnected /] connect
> Connected to domain controller at localhost:9999
> ----
> But no "Connected to domain controller" is output. No indication of success is given other than the next line of the CLI has the hostname (localhost) referenced.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 20:37:29 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 29 Jan 2014 20:37:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.21979.1391045849120@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939928#comment-12939928 ] 

Davide Sottara commented on DROOLS-418:
---------------------------------------

I have just realized that "type == LOW" must be a constraint in a different rule from the one you posted..
I'll run the decision table and get back to you
                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 20:53:28 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 29 Jan 2014 20:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.21995.1391046808873@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939928#comment-12939928 ] 

Davide Sottara edited comment on DROOLS-418 at 1/29/14 8:51 PM:
----------------------------------------------------------------

I have just realized that "type == LOW" must be a constraint in a different rule from the one you posted.. That is the one generated from the DT, but do you have other rules in your KB?
                
      was (Author: dsotty):
    I have just realized that "type == LOW" must be a constraint in a different rule from the one you posted..
I'll run the decision table and get back to you
                  
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 20:57:28 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Wed, 29 Jan 2014 20:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.22009.1391047048688@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939928#comment-12939928 ] 

Davide Sottara edited comment on DROOLS-418 at 1/29/14 8:55 PM:
----------------------------------------------------------------

I have just realized that "type == LOW" must be a constraint in a different rule from the one you posted.. That is the one generated from the DT, but I guess you have other rules in your KB: the exception stack trace shows an accumulate being involved. Could you please post the full DRL you are using? 
Thanks
Davide
                
      was (Author: dsotty):
    I have just realized that "type == LOW" must be a constraint in a different rule from the one you posted.. That is the one generated from the DT, but do you have other rules in your KB?
                  
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 23:01:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 23:01:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454472@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454472@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454472.22047.1391054488743@jira02.app.mwc.hst.phx2.redhat.com>

Brad Maxwell created WFLY-2840:
----------------------------------

             Summary: @Schedule EJB Timer not using timezone when calcualting next timeout
                 Key: WFLY-2840
                 URL: https://issues.jboss.org/browse/WFLY-2840
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
    Affects Versions: 8.0.0.CR1
            Reporter: Brad Maxwell
            Assignee: David Lloyd


With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.

  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014


import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Startup
@Singleton
public class ScheduleTest {
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
  public void helloWorld(Timer time) {
    System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
  }
}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 23:03:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 23:03:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.22049.1391054608529@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939936#comment-12939936 ] 

Brad Maxwell commented on WFLY-2840:
------------------------------------

The issue appears to be in 
org.jboss.as.ejb3.timerservice.task.CalendarTimerTask

It looks like calculateNextTimeout, Calendar cal = new GregorianCalendar(), should take in the timezone specified in the ScheduleExpression, such as :

TimeZone tz = TimeZone.getTimeZone(((CalendarTimer) timer).getCalendarTimeout().getScheduleExpression().getTimezone());
        Calendar cal = new GregorianCalendar(tz);
  
Currently:

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014

With Change:

21:51:00,025 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 21:52:00 CST 2014
21:52:00,002 INFO  [stdout] (EJB default - 2) ScheduleTest: nextTimeout:Wed Jan 29 21:53:00 CST 2014
...
                
> @Schedule EJB Timer not using timezone when calcualting next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 23:05:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 23:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.22053.1391054728715@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-2840:
-------------------------------

    Description: 
With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.

[code]
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014


import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Startup
@Singleton
public class ScheduleTest {
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
  public void helloWorld(Timer time) {
    System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
  }
}


  was:
With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.

  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014


import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Startup
@Singleton
public class ScheduleTest {
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
  public void helloWorld(Timer time) {
    System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
  }
}



    
> @Schedule EJB Timer not using timezone when calcualting next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
> [code]
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Wed Jan 29 23:05:29 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Wed, 29 Jan 2014 23:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.22055.1391054729051@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-2840:
-------------------------------

    Description: 
With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.

{code}
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
{code}

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014

{code}
import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Startup
@Singleton
public class ScheduleTest {
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
  public void helloWorld(Timer time) {
    System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
  }
}
{code}

  was:
With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.

[code]
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014


import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Startup
@Singleton
public class ScheduleTest {
  @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
  public void helloWorld(Timer time) {
    System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
  }
}



    
> @Schedule EJB Timer not using timezone when calcualting next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
> {code}
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> {code}
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> {code}
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }
> {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 issues at jboss.org  Thu Jan 30 00:41:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 30 Jan 2014 00:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.22091.1391060488655@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939936#comment-12939936 ] 

Brad Maxwell edited comment on WFLY-2840 at 1/30/14 12:39 AM:
--------------------------------------------------------------

The issue appears to be in 


org.jboss.as.ejb3.timerservice.task.CalendarTimerTask

It looks like calculateNextTimeout, Calendar cal = new GregorianCalendar(), should take in the timezone specified in the ScheduleExpression, such as :

TimeZone tz = TimeZone.getTimeZone(((CalendarTimer) timer).getCalendarTimeout().getScheduleExpression().getTimezone());
        Calendar cal = new GregorianCalendar(tz);

Or actually, CalendarTimerTask is calling  CalendarBasedTimeout.getNextTimeout which takes in the calendar created from CalendarTimerTask, and it has access to the scheduleExpression, so that is probably the better place to change it.

org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout.getNextTimeout

        nextCal.setTimeZone(TimeZone.getTimeZone(scheduleExpression.getTimezone()));

  
Currently:

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014

With Change:

21:51:00,025 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 21:52:00 CST 2014
21:52:00,002 INFO  [stdout] (EJB default - 2) ScheduleTest: nextTimeout:Wed Jan 29 21:53:00 CST 2014
...
                
      was (Author: bmaxwell):
    The issue appears to be in 
org.jboss.as.ejb3.timerservice.task.CalendarTimerTask

It looks like calculateNextTimeout, Calendar cal = new GregorianCalendar(), should take in the timezone specified in the ScheduleExpression, such as :

TimeZone tz = TimeZone.getTimeZone(((CalendarTimer) timer).getCalendarTimeout().getScheduleExpression().getTimezone());
        Calendar cal = new GregorianCalendar(tz);
  
Currently:

21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014

With Change:

21:51:00,025 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 21:52:00 CST 2014
21:52:00,002 INFO  [stdout] (EJB default - 2) ScheduleTest: nextTimeout:Wed Jan 29 21:53:00 CST 2014
...
                  
> @Schedule EJB Timer not using timezone when calcualting next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
> {code}
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> {code}
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> {code}
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }
> {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 issues at jboss.org  Thu Jan 30 06:31:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 30 Jan 2014 06:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad
	passwords
In-Reply-To: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503730.1381946649000.22560.1391081489129@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939996#comment-12939996 ] 

Darran Lofthouse commented on WFLY-2322:
----------------------------------------

Actually it is only a one line change ;-)  Overall the reasoning is ship by default mandating the password restrictions and an administrator can make the one line change and relax the checking again.

In the past this is just one of those areas we have been called out on that we don't enforce password strength rules.
                
> Update add-user to REJECT bad passwords
> ---------------------------------------
>
>                 Key: WFLY-2322
>                 URL: https://issues.jboss.org/browse/WFLY-2322
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 06:43:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 30 Jan 2014 06:43:28 -0500 (EST)
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.22588.1391082208723@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 resolved WFLY-1597.
------------------------------------

    Resolution: Done

    
> 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: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Thu Jan 30 06:49:29 2014
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 30 Jan 2014 06:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta]
 (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException"
 on reload
In-Reply-To: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530612.1390998643000.22601.1391082569012@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-2828:
--------------------------------

    Component/s: EJB
                     (was: Transactions)

    
> "WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2828
>                 URL: https://issues.jboss.org/browse/WFLY-2828
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Tom Jenkinson
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> 	at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {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 issues at jboss.org  Thu Jan 30 06:49:29 2014
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 30 Jan 2014 06:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta]
 (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException"
 on reload
In-Reply-To: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530612.1390998643000.22605.1391082569473@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-2828:
--------------------------------

    Assignee: David Lloyd  (was: Tom Jenkinson)

    
> "WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2828
>                 URL: https://issues.jboss.org/browse/WFLY-2828
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: David Lloyd
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> 	at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {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 issues at jboss.org  Thu Jan 30 06:49:29 2014
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 30 Jan 2014 06:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2828) "WARN [com.arjuna.ats.jta]
 (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException"
 on reload
In-Reply-To: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530612.1390998643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530612.1390998643000.22609.1391082569697@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12939999#comment-12939999 ] 

Tom Jenkinson commented on WFLY-2828:
-------------------------------------

Looks like it is coming out of the EJB code, so reassigning to EJB default component owner
                
> "WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException" on reload
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2828
>                 URL: https://issues.jboss.org/browse/WFLY-2828
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: David Lloyd
>
> About 1/4 times.
> {noformat}
> 13:26:27,786 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 7076ms
> 13:26:27,787 INFO  [org.jboss.as] (MSC service thread 1-5) JBAS015899: WildFly 8.0.0.Final-SNAPSHOT "WildFly" starting
> 13:26:27,861 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:26:27,874 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 35) JBAS010280: Activating Infinispan subsystem.
> 13:26:27,875 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
> 13:26:27,877 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 39) JBAS010260: Activating JGroups subsystem.
> 13:26:27,894 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 45) JBAS011800: Activating Naming Subsystem
> 13:26:27,895 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:26:27,897 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,897 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017502: Undertow 1.0.0.Beta33 starting
> 13:26:27,900 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.20.Final
> 13:26:27,900 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:26:27,901 WARN  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011706: Metric of type 'mem' is no longer supported and will be ignored.
> 13:26:27,901 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:26:27,901 INFO  [org.wildfly.extension.mod_cluster] (ServerService Thread Pool -- 44) JBAS011704: Mod_cluster uses default load balancer provider
> 13:26:27,901 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:26:27,904 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
> 13:26:27,906 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 53) JBAS017527: Creating file handler for path /home/rhusar/as/build/target/wildfly-8.0.0.Final-SNAPSHOT/welcome-content
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017525: Started server default-server.
> 13:26:27,909 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) JBAS017531: Host default-host starting
> 13:26:27,915 WARN  [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> 	at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {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 issues at jboss.org  Thu Jan 30 07:07:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 30 Jan 2014 07:07:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2837) "UT015005: Error invoking
 method requestDestroyed on listener class ..." on clean shutdown with
 session draining
In-Reply-To: <JIRA.12530676.1391021894000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530676.1391021894000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530676.1391021894000.22806.1391083649004@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940128#comment-12940128 ] 

Stuart Douglas commented on WFLY-2837:
--------------------------------------

The issue is that requests can still be in progress when the server is shut down. There is a graceful shutdown handler that we can use, but it should be part of the broader graceful shutdown effort.
                
> "UT015005: Error invoking method requestDestroyed on listener class ..." on clean shutdown with session draining
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2837
>                 URL: https://issues.jboss.org/browse/WFLY-2837
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Stuart Douglas
>
> When using mod_cluster session draining and shutting down, draining for 10 seconds results in problem with invoking requestDestroyed listener event.
> Seems to me like dependency orchestration problem on shutdown..
> {noformat}
> 19:01:31,978 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-ejb-1.1.0-SNAPSHOT.jar) in 437ms
> 19:01:31,978 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: clusterbench-ee7-web-1.1.0-SNAPSHOT.war) in 462ms
> 19:01:31,981 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment clusterbench-ee7.ear (runtime-name: clusterbench-ee7.ear) in 441ms
> 19:01:35,505 INFO  [org.jboss.test.clusterbench.web.load.AverageSystemLoadServlet] (default task-2) DONE, I was stressing CPU with 4 evil threads for 5027 milliseconds (including warm-up).
> 19:01:35,510 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: java.lang.RuntimeException: javax.servlet.ServletException: UT010013: Could not instantiate com.sun.faces.config.ConfigureListener
> 	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:77) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:297) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:685) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: javax.servlet.ServletException: UT010013: Could not instantiate com.sun.faces.config.ConfigureListener
> 	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:50) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:75) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	... 11 more
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:97)
> 	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:41)
> 	at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1132)
> 	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:48) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	... 12 more
> 19:01:35,513 ERROR [io.undertow.servlet.request] (default task-2) UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldInitialListener: java.lang.RuntimeException: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.servlet.WeldInitialListener
> 	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:77) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.core.ApplicationListeners.get(ApplicationListeners.java:297) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:685) [undertow-core-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: javax.servlet.ServletException: UT010013: Could not instantiate org.jboss.weld.servlet.WeldInitialListener
> 	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:50) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	at io.undertow.servlet.core.ManagedListener.instance(ManagedListener.java:75) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	... 11 more
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:97)
> 	at org.jboss.as.ee.component.ComponentStartService.getValue(ComponentStartService.java:41)
> 	at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$5.createInstance(UndertowDeploymentInfoService.java:1132)
> 	at io.undertow.servlet.core.ManagedListener.start(ManagedListener.java:48) [undertow-servlet-1.0.0.Beta33.jar:1.0.0.Beta33]
> 	... 12 more
> 19:01:41,578 INFO  [org.jboss.modcluster] (MSC service thread 1-6) MODCLUSTER000021: All pending requests drained from default-host:/clusterbench in 10.0 seconds
> 19:01:41,580 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 60) MODCLUSTER000002: Initiating mod_cluster shutdown
> 19:01:41,580 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017521: Undertow AJP listener ajp suspending
> 19:01:41,582 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 19:01:41,583 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017506: Undertow 1.0.0.Beta33 stopping
> 19:01:41,586 INFO  [org.jboss.as] (MSC service thread 1-4) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 10026ms
> {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 issues at jboss.org  Thu Jan 30 07:23:29 2014
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Thu, 30 Jan 2014 07:23:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554403@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554403@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554403.22859.1391084609583@jira02.app.mwc.hst.phx2.redhat.com>

Martin Andersson created WFLY-2841:
--------------------------------------

             Summary: Datasource mapped in jboss-web.xml not available to persistence unit
                 Key: WFLY-2841
                 URL: https://issues.jboss.org/browse/WFLY-2841
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Martin Andersson


I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.

In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}


A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 07:47:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 30 Jan 2014 07:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1873) mod_cluster ISE on shutdown
In-Reply-To: <JIRA.12498516.1376424073000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498516.1376424073000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498516.1376424073000.22905.1391086048728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940147#comment-12940147 ] 

Michal Babacek commented on WFLY-1873:
--------------------------------------

The attached PR fixes the issue, my test is no longer able to hit the ISE.
                
> mod_cluster ISE on shutdown
> ---------------------------
>
>                 Key: WFLY-1873
>                 URL: https://issues.jboss.org/browse/WFLY-1873
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> 16:45:28,305 ERROR [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (MSC service thread 1-2) Error [MEM: MEM: Can't read node: {4}] sending command DISABLE-APP to proxy localhost/127.0.0.1:6666, configuration will be reset
> 16:45:28,315 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow AJP listener ajp suspending
> 16:45:28,319 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 16:45:28,336 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010418: Stopped Driver service with driver-name = h2
> 16:45:28,344 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow HTTP listener default suspending
> 16:45:28,349 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 16:45:38,307 WARN  [org.jboss.modcluster.ModClusterService] (MSC service thread 1-2) Failed to drain pending requests from context [org.wildfly.mod_cluster.undertow.UndertowContext at 1906d941] within specified timeout: 10 seconds
> 16:45:38,308 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000004: Failure during stop of service jboss.undertow.deployment.default-host./clusterbench-ee6-web: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.onDeploymentStop(UndertowEventHandlerAdapter.java:137)
> 	at org.wildfly.extension.undertow.Host$2.invoke(Host.java:138)
> 	at org.wildfly.extension.undertow.UndertowService.fireEvent(UndertowService.java:168)
> 	at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:135)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:104)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2052) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2013) [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]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 07:47:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 30 Jan 2014 07:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2842) Add TRACE logging for user
 search in security realms as well
In-Reply-To: <JIRA.12530737.1391085958348@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530737.1391085958348@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530737.1391085958348.22907.1391086048816@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2842:
--------------------------------------

             Summary: Add TRACE logging for user search in security realms as well
                 Key: WFLY-2842
                 URL: https://issues.jboss.org/browse/WFLY-2842
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Final


Trace logging has been added for group loading within security realms, the same should be added for the user search 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 issues at jboss.org  Thu Jan 30 07:51:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 30 Jan 2014 07:51:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2843) Bring LDAP config for
 authentication and user loading within authorization into one.
In-Reply-To: <JIRA.12530738.1391086197479@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530738.1391086197479@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530738.1391086197479.22918.1391086288598@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2843:
--------------------------------------

             Summary: Bring LDAP config for authentication and user loading within authorization into one.
                 Key: WFLY-2843
                 URL: https://issues.jboss.org/browse/WFLY-2843
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Final


Adding support for group loading for LDAP an additional definition for user searching was introduced, this should be re-used for the authentication step.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 09:19:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 30 Jan 2014 09:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2289) deployed webapp before
 mod_cluster httpd discovery aren't see by httpd.
In-Reply-To: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502817.1381495589000.23015.1391091568983@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Babacek closed WFLY-2289.
--------------------------------



My tests, but for several cases specifically targeted at deploy/undeploy failover, have webapps deployed *before* httpd discovery and I can't see the issue now.  Closing.
                
> deployed webapp before mod_cluster httpd discovery aren't see by httpd.
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2289
>                 URL: https://issues.jboss.org/browse/WFLY-2289
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>             Fix For: 8.0.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 issues at jboss.org  Thu Jan 30 09:33:29 2014
From: issues at jboss.org (Martin Grigorov (JIRA))
Date: Thu, 30 Jan 2014 09:33:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2844) HandshakeRequest doesn't
 implement some methods
In-Reply-To: <JIRA.12530751.1391092333232@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530751.1391092333232@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530751.1391092333232.23122.1391092409013@jira02.app.mwc.hst.phx2.redhat.com>

Martin Grigorov created WFLY-2844:
-------------------------------------

             Summary: HandshakeRequest doesn't implement some methods
                 Key: WFLY-2844
                 URL: https://issues.jboss.org/browse/WFLY-2844
             Project: WildFly
          Issue Type: Clarification
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
         Environment: Wildfly 8.0.0CR1
            Reporter: Martin Grigorov
            Assignee: Stuart Douglas
            Priority: Minor


My app is a .war file, deployed in $WFLY/standalone/deployments. It uses programmatic way (ServerApplicationConfig) to deploy web socket endpoint:
15:12:33,024 INFO  [io.undertow.websockets.jsr] (MSC service thread 1-7) UT026005: Adding programmatic server endpoint class org.apache.wicket.protocol.ws.javax.WicketEndpoint for path /wicket/websocket

The configured ServerEndpointConfig uses custom Configurator to collect some data from the handshake request. More specifically I need the http session id.

javax.websocket.server.HandshakeRequest#getHttpSession() method has the following javadoc:

     * @return the http session or {@code null} if either the websocket
     * implementation is not part of a Java EE web container, or there is
     * no HttpSession associated with the opening handshake request.

The HttpSession is bound before making the websocket request and I think the app is running in a Java EE web container, so handshkeRequest#getHttpSession() must not be null. But it is ...


Additionally I see that javax.websocket.server.HandshakeRequest#getParameterMap() seems to be not implemented too.
The websocket upgrade request has query string, and javax.websocket.server.HandshakeRequest#getQueryString() properly returns its value, but #getParameterMap() is empty. 
I expect the map to contain the parsed parameters from the query string.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 09:43:28 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 30 Jan 2014 09:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2845) On WildFly clean shutdown:
 failed marshalling rsp (UnsuccessfulResponse)
In-Reply-To: <JIRA.12530755.1391092956946@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530755.1391092956946@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530755.1391092956946.23148.1391093008971@jira02.app.mwc.hst.phx2.redhat.com>

Michal Babacek created WFLY-2845:
------------------------------------

             Summary: On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
                 Key: WFLY-2845
                 URL: https://issues.jboss.org/browse/WFLY-2845
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
         Environment: RHEL6 x86_64; Oracle JDK 7
            Reporter: Michal Babacek
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Final


I've got two standalone-ha instances running on a one box. Each of these instances has  [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:

{noformat}
08:59:33,341 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
08:59:33,368 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
08:59:33,392 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms

{noformat}

In the log.  It's a non-deterministic problem and it does not emerge always.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 09:43:29 2014
From: issues at jboss.org (Geert Coelmont (JIRA))
Date: Thu, 30 Jan 2014 09:43:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-254) tomcatAuthentication attribute
 on the AJP connector
In-Reply-To: <JIRA.12445093.1313755997000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445093.1313755997000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445093.1313755997000.23161.1391093009955@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940189#comment-12940189 ] 

Geert Coelmont commented on WFLY-254:
-------------------------------------

This issue should be reopened as jboss-web was replaced by undertow. In undertow this system property is not used, so this fix isn't useful.
Is there perhaps any other way in undertow to achieve the same?

                
> tomcatAuthentication attribute on the AJP connector
> ---------------------------------------------------
>
>                 Key: WFLY-254
>                 URL: https://issues.jboss.org/browse/WFLY-254
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>         Environment: Windows Server 2003 32 bit, IIS 6, tomcat connector 1.2.28 used as an extension
>            Reporter: Brett Prucha
>            Assignee: Jean-Frederic Clere
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> In JBoss 5.1.0 I could set the tomcatAuthentication attribute of the AJP connector to false to allow IIS to handle the authentication and pass that along to JBoss. I'm wanting to upgrade to JBoss 7 but unable to set this attribute in version 7.0.0 final to make this work. This attribute is descibed in the tomcat documentation at http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.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 issues at jboss.org  Thu Jan 30 09:45:29 2014
From: issues at jboss.org (Michal Babacek (JIRA))
Date: Thu, 30 Jan 2014 09:45:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2845) On WildFly clean shutdown:
 failed marshalling rsp (UnsuccessfulResponse)
In-Reply-To: <JIRA.12530755.1391092956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530755.1391092956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530755.1391092956000.23166.1391093129555@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Babacek updated WFLY-2845:
---------------------------------

    Description: 
I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}}  [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:

{noformat}
08:59:33,341 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
08:59:33,368 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
08:59:33,392 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms

{noformat}

In the log.  It's a non-deterministic problem and it does not emerge always.

  was:
I've got two standalone-ha instances running on a one box. Each of these instances has  [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:

{noformat}
08:59:33,341 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
08:59:33,368 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
08:59:33,392 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms

{noformat}

In the log.  It's a non-deterministic problem and it does not emerge always.


    
> On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2845
>                 URL: https://issues.jboss.org/browse/WFLY-2845
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: RHEL6 x86_64; Oracle JDK 7
>            Reporter: Michal Babacek
>            Assignee: Paul Ferraro
>              Labels: clustering
>             Fix For: 8.0.0.Final
>
>
> I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}}  [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws:
> {noformat}
> 08:59:33,341 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web]
> 08:59:33,368 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher
> 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException
> 08:59:33,392 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms
> {noformat}
> In the log.  It's a non-deterministic problem and it does not emerge always.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 10:03:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 10:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.23232.1391094209545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940198#comment-12940198 ] 

RH Bugzilla Integration commented on DROOLS-364:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1058254|https://bugzilla.redhat.com/show_bug.cgi?id=1058254] from NEW to ASSIGNED
                
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mark Proctor
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Thu Jan 30 10:03:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 10:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.23233.1391094209610@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-364:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1058254

    
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mark Proctor
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Thu Jan 30 10:15:31 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Thu, 30 Jan 2014 10:15:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.23258.1391094931128@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940207#comment-12940207 ] 

Nedo Nedic commented on DROOLS-418:
-----------------------------------

Sorry Davide, I realized there was an issue in my code. I just don't know why the compiler were not complaining about it, because I had the condition like this:

$l:ArrayList(size > 0, type=="LOW")

Obviously, ArrayList dosen't have "type" attribute.
                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 10:15:31 2014
From: issues at jboss.org (Nedo Nedic (JIRA))
Date: Thu, 30 Jan 2014 10:15:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.23263.1391094931422@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940207#comment-12940207 ] 

Nedo Nedic edited comment on DROOLS-418 at 1/30/14 10:15 AM:
-------------------------------------------------------------

Sorry Davide, I realized there was an issue in my code. I just don't know why the compiler were not complaining about it, because I had the condition like this:

$l:ArrayList(size > 0, type=="LOW")

Obviously, ArrayList doesn't have "type" attribute.
                
      was (Author: nedoo):
    Sorry Davide, I realized there was an issue in my code. I just don't know why the compiler were not complaining about it, because I had the condition like this:

$l:ArrayList(size > 0, type=="LOW")

Obviously, ArrayList dosen't have "type" attribute.
                  
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 10:35:32 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Thu, 30 Jan 2014 10:35:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2846) Add help text to CLI GUI
In-Reply-To: <JIRA.12530761.1391096083826@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530761.1391096083826@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530761.1391096083826.23313.1391096132857@jira02.app.mwc.hst.phx2.redhat.com>

Stan Silvert created WFLY-2846:
----------------------------------

             Summary: Add help text to CLI GUI
                 Key: WFLY-2846
                 URL: https://issues.jboss.org/browse/WFLY-2846
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: 8.0.0.CR1
            Reporter: Stan Silvert
            Assignee: Stan Silvert


Add a help link from CLI GUI to https://community.jboss.org/wiki/AGUIForTheCommandLineInterface

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 10:37:29 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Thu, 30 Jan 2014 10:37:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2846) Add help text to CLI GUI
In-Reply-To: <JIRA.12530761.1391096083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530761.1391096083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530761.1391096083000.23315.1391096249214@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated WFLY-2846:
-------------------------------

    Priority: Minor  (was: Major)

    
> Add help text to CLI GUI
> ------------------------
>
>                 Key: WFLY-2846
>                 URL: https://issues.jboss.org/browse/WFLY-2846
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>            Priority: Minor
>
> Add a help link from CLI GUI to https://community.jboss.org/wiki/AGUIForTheCommandLineInterface

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 10:55:28 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 30 Jan 2014 10:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.23359.1391097328696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940228#comment-12940228 ] 

Davide Sottara commented on DROOLS-418:
---------------------------------------

No problem. I will close this ticket.

                
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 10:57:28 2014
From: issues at jboss.org (Davide Sottara (JIRA))
Date: Thu, 30 Jan 2014 10:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-418) MVEL Unable to resolve
 method exception on fact update
In-Reply-To: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530418.1390837742000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530418.1390837742000.23362.1391097448707@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara resolved DROOLS-418.
-----------------------------------

    Resolution: Rejected

    
> MVEL Unable to resolve method exception on fact update
> ------------------------------------------------------
>
>                 Key: DROOLS-418
>                 URL: https://issues.jboss.org/browse/DROOLS-418
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Linux Mint 15
> Jboss 5.1
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>         Attachments: Classifier.xls
>
>
> The following rule will fail with an exception after update is called on a fact:
> 	rule "Classifier"
> 	    no-loop true
> 	    salience 65430
>             when
> 	          $sn:Snort(sig_priority == "1", type == null)
>             then
> 	          $sn.setType("LOW");
> 	          update($sn);
>             end
> Snort fact type declaration:
> 	declare Snort
> 	    @role( event )
> 	    @timestamp( event_date )
> 	    @expires( 1h )
> 	    dport: String
> 	    data: String
> 	    sport: String
> 	    hostname: String
> 	    type: String
> 	    sig_priority: String
> 	    sensor: String
>             id: java.lang.Long
> 	    sig_class_name: String
> 	    ip_dst: String
> 	    sig_name: String
> 	    event_date: java.util.Date
>             ip_src: String
> 	end
> [Error: unable to resolve method: java.util.ArrayList.type() [arglength=0]]
> [Near : {... type == "LOW" ....}]
>              ^
> [Line: 1, Column: 1]
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1071)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:980)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:670)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanPropertyAO(ReflectiveAccessorOptimizer.java:465)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:370)
>         at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:140)
>         at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>         at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>         at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:114)
>         at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
>         at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>         at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>         at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:73)
>         at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:52)
>         at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:218)
>         at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
>         at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:655)
>         at org.drools.reteoo.ReteooWorkingMemory$EvaluateResultConstraints.execute(ReteooWorkingMemory.java:594)
>         at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:364)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:327)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:894)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 11:03:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 11:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.23378.1391097809389@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940232#comment-12940232 ] 

RH Bugzilla Integration commented on DROOLS-364:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1058254|https://bugzilla.redhat.com/show_bug.cgi?id=1058254] from ASSIGNED to MODIFIED
                
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mark Proctor
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Thu Jan 30 11:05:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 30 Jan 2014 11:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.23385.1391097929251@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-364:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mario Fusco
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Thu Jan 30 11:05:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 30 Jan 2014 11:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-364) ClasspathKieProject fails
 vfs: path for jar deployments and exploded ear
In-Reply-To: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527146.1386272749000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527146.1386272749000.23388.1391097929897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-364.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done

    
> ClasspathKieProject fails vfs: path for jar deployments and exploded ear
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-364
>                 URL: https://issues.jboss.org/browse/DROOLS-364
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: JBoss AS 7.1.1
>            Reporter: Nicolas-Xavier Vanderlinden
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log
>
>
> Drools is not able to load kmodule.xml from an exploded ear.
> 17:24:45,116 WARN  Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent
> null
> 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 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 issues at jboss.org  Thu Jan 30 11:37:28 2014
From: issues at jboss.org (Matus Abaffy (JIRA))
Date: Thu, 30 Jan 2014 11:37:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2847) Caller's security identity
 doesn't get propagated by default
In-Reply-To: <JIRA.12530767.1391099797552@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530767.1391099797552@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530767.1391099797552.23463.1391099848773@jira02.app.mwc.hst.phx2.redhat.com>

Matus Abaffy created WFLY-2847:
----------------------------------

             Summary: Caller's security identity doesn't get propagated by default
                 Key: WFLY-2847
                 URL: https://issues.jboss.org/browse/WFLY-2847
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB, Security
    Affects Versions: 8.0.0.CR1
            Reporter: Matus Abaffy
            Assignee: David Lloyd


3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
{{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}

Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.

According to EJB spec, 12 Security management, 12.1 Overview:
bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
12.3.4 Specification of Security Identities in the Deployment Descriptor:
bq. "The Bean Provider or Application Assembler typically specifies whether the caller?s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller?s security identity is used."
etc.
{code}
@RunAs("printer")
@PermitAll
public class Printer {
    @EJB
    HelperBean hb;

    public void invokeHelperBean() {
        hb.invokeToner();
    }
}
{code}
{code}
@Stateful
public class HelperBean {
    @EJB
    Toner toner;

    public void invokeToner() {
        toner.spill();
    }
}
{code}
{code}
@Stateless
@RolesAllowed("printer")
public class Toner {
    public void spill() {}
}
{code}
A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Thu Jan 30 12:15:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 30 Jan 2014 12:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-402) Programmatic rule update
	fails
In-Reply-To: <JIRA.12529486.1389790486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529486.1389790486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529486.1389790486000.23600.1391102129605@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-402.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done


There was a small bug when using the default releaseId. Fixed.
                
> Programmatic rule update fails
> ------------------------------
>
>                 Key: DROOLS-402
>                 URL: https://issues.jboss.org/browse/DROOLS-402
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Windows 7
>            Reporter: Markus Tippmann
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: drools.test.zip
>
>
> Programmatic construction of a kmodule and updating its rules fails with different problems. 
> I attach a small Maven project which runs 3 tests (one succeeds just for demonstration). I hope I'm doing correctly here on kmodule construction.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 12:23:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 30 Jan 2014 12:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2848) Pull the username from LDAP
 in security realms
In-Reply-To: <JIRA.12530773.1391102570948@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530773.1391102570948@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530773.1391102570948.23636.1391102608657@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2848:
--------------------------------------

             Summary: Pull the username from LDAP in security realms
                 Key: WFLY-2848
                 URL: https://issues.jboss.org/browse/WFLY-2848
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Final


The user could have entered the username in a different case to what is stored in LDAP, a simple reload of their username using the attribute will correct 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 issues at jboss.org  Thu Jan 30 12:49:29 2014
From: issues at jboss.org (Frank Cornelis (JIRA))
Date: Thu, 30 Jan 2014 12:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.23674.1391104169092@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940270#comment-12940270 ] 

Frank Cornelis commented on WFLY-2809:
--------------------------------------

There is a patch available for this: https://github.com/wildfly/wildfly/pull/5801
I've tested it out with 2 huge real-world applications. The patch works as expected.
Could this issue be scheduled for 8.0.0.Final inclusion?
                
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: Stefan Guilhen
>            Priority: Blocker
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Thu Jan 30 13:39:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 30 Jan 2014 13:39:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554000.23814.1391107168870@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940291#comment-12940291 ] 

Scott Marlow commented on WFLY-2841:
------------------------------------

It sounds like an internal ordering problem during deployment of your app.  

What happens if you set wildfly.jpa.twophasebootstrap to false in the persistence.xml?  The persistence unit should deploy later as a result.

{quote}
<property name="wildfly.jpa.twophasebootstrap" value="false"/>
{quote}

Should look like:

{quote}
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.1" 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="wfdsPU" transaction-type="JTA">
        <jta-data-source>java:comp/env/MyDS</jta-data-source>
    <properties>
                <property name="wildfly.jpa.twophasebootstrap" value="false"/>
                <property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/>
                <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
        </properties>
  </persistence-unit>
</persistence>
{quote}
                
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
>                 Key: WFLY-2841
>                 URL: https://issues.jboss.org/browse/WFLY-2841
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 13:43:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 13:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2753) Workaround for auditlog
 syslog appName not being configurable
In-Reply-To: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529444.1389762705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529444.1389762705000.23819.1391107408653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940292#comment-12940292 ] 

RH Bugzilla Integration commented on WFLY-2753:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1053355|https://bugzilla.redhat.com/show_bug.cgi?id=1053355] from MODIFIED to ASSIGNED
                
> Workaround for auditlog syslog appName not being configurable
> -------------------------------------------------------------
>
>                 Key: WFLY-2753
>                 URL: https://issues.jboss.org/browse/WFLY-2753
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kyle Lape
>            Assignee: Kyle Lape
>             Fix For: 8.0.0.Final
>
>
> Use {{-Dorg.jboss.TEMP.audit.log.appName=customApp}} where the value is the {{app-name}} as mentioned in section 6.2.5 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 13:45:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 13:45:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2746) Workaround for auditlog
 syslog Facility not being configurable
In-Reply-To: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529184.1389610106000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529184.1389610106000.23822.1391107529158@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940293#comment-12940293 ] 

RH Bugzilla Integration commented on WFLY-2746:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1052187|https://bugzilla.redhat.com/show_bug.cgi?id=1052187] from MODIFIED to ASSIGNED
                
> Workaround for auditlog syslog Facility not being configurable
> --------------------------------------------------------------
>
>                 Key: WFLY-2746
>                 URL: https://issues.jboss.org/browse/WFLY-2746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> Use -Dorg.jboss.TEMP.audit.log.facility=5 where the number is the FACILITY as mentioned in section 6.2.1 of RFC-5424

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 13:53:28 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Thu, 30 Jan 2014 13:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2846) Add help text to CLI GUI
In-Reply-To: <JIRA.12530761.1391096083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530761.1391096083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530761.1391096083000.23830.1391108008498@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated WFLY-2846:
-------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5827

    
> Add help text to CLI GUI
> ------------------------
>
>                 Key: WFLY-2846
>                 URL: https://issues.jboss.org/browse/WFLY-2846
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>            Priority: Minor
>
> Add a help link from CLI GUI to https://community.jboss.org/wiki/AGUIForTheCommandLineInterface

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 13:53:28 2014
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Thu, 30 Jan 2014 13:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2846) Add help text to CLI GUI
In-Reply-To: <JIRA.12530761.1391096083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530761.1391096083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530761.1391096083000.23834.1391108008578@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved WFLY-2846.
--------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> Add help text to CLI GUI
> ------------------------
>
>                 Key: WFLY-2846
>                 URL: https://issues.jboss.org/browse/WFLY-2846
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Add a help link from CLI GUI to https://community.jboss.org/wiki/AGUIForTheCommandLineInterface

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 13:53:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 30 Jan 2014 13:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1523) Addition of caching for
 security realms backed by ldap.
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.23833.1391108008551@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:
-----------------------------------

    Summary: Addition of caching for security realms backed by ldap.  (was: Addition of caching for backing store access used by realms.)

    
> Addition of caching for security realms backed by ldap.
> -------------------------------------------------------
>
>                 Key: WFLY-1523
>                 URL: https://issues.jboss.org/browse/WFLY-1523
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Thu Jan 30 14:09:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 14:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.23856.1391108968842@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2839:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059836

    
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:13:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 14:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.23861.1391109208524@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2839:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059836, https://bugzilla.redhat.com/show_bug.cgi?id=1059837  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1059836)

    
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:25:29 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 30 Jan 2014 14:25:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with
 kieServices.newKieContainer() with LATEST or RELEASE instead of explicit
 version number (eg: 0.0.1) on a application where the KIE module Rule
 artifact project kjar has been locally-installed from remote Maven
 repository.
In-Reply-To: <JIRA.12530799.1391109809917@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530799.1391109809917@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530799.1391109809917.23875.1391109929241@jira02.app.mwc.hst.phx2.redhat.com>

Matteo Mortari created DROOLS-419:
-------------------------------------

             Summary: "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
                 Key: DROOLS-419
                 URL: https://issues.jboss.org/browse/DROOLS-419
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.1.Final
         Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933
            Reporter: Matteo Mortari
            Assignee: Mark Proctor
         Attachments: 20140130.drools6testmvnlatest.zip

Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.

More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , I mean that before launching Application, I performed 
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
{code}

h5. Disclaimer
I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.

h5. DETAILS
Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .

Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
{code:title=App.java}
public static void main( String[] args ) {
	KieServices kieServices = KieServices.Factory.get();
	ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
	KieContainer kContainer = kieServices.newKieContainer( releaseId );
	KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
	kieBaseConf.setOption( EventProcessingOption.STREAM );
	KieBase kBase = kContainer.newKieBase(kieBaseConf);
	for ( KiePackage a : kBase.getKiePackages()) {
			for (Rule r : a.getRules()) {
				logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
			}
	}
}
{code}

The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
{code}

Execution of
{code}
java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
{code}

Would generate the following stack trace
{code}
Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
        at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
        at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
{code}

Same for LATEST as launch parameter.

But fixed version, eg: 0.0.2 as launch parameter, will work.
{code}
D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
2014-01-30 19:24:12,128 [main] INFO  org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
2014-01-30 19:24:12,440 [main] INFO  com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
{code}

Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
{code}
D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
????drools6testmvnlatest.therules
    ?   maven-metadata-nexus-hostname-nexus.xml
    ?   maven-metadata-nexus-hostname-nexus.xml.sha1
    ?   maven-metadata-temp.xml
    ?   maven-metadata-temp.xml.sha1
    ?   resolver-status.properties
    ?
    ????0.0.2
            drools6testmvnlatest.therules-0.0.2.jar
            drools6testmvnlatest.therules-0.0.2.jar.sha1
            drools6testmvnlatest.therules-0.0.2.pom
            drools6testmvnlatest.therules-0.0.2.pom.sha1
            _remote.repositories
{code}

h5. WORKAROUND
The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
h6. Workaround Option 1
Do 'fake' a pom.xml with the dependency, something similar to:
{code}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.acme</groupId>
  <artifactId>fakepom</artifactId>
  <version>0.0.1</version>
  <packaging>jar</packaging>

  <dependencies>
    <dependency>
      <groupId>com.acme</groupId>
      <artifactId>drools6testmvnlatest.therules</artifactId>
      <version>RELEASE</version>
    </dependency>
  </dependencies>
  
</project>
{code}

And then launch maven in the same directory of this 'fake' pom.xml with the following command:
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline 
{code}

This usually generate the 'maven-metadata-local' file in the local .m2 repo:
{code}
D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
????drools6testmvnlatest.therules
    ?   maven-metadata-nexus-hostname-nexus.xml
    ?   maven-metadata-nexus-hostname-nexus.xml.sha1
    ?   maven-metadata-local.xml
    ?   maven-metadata-local.xml.sha1
    ?   maven-metadata-temp.xml
    ?   maven-metadata-temp.xml.sha1
    ?   resolver-status.properties
    ?
    ????0.0.2
            drools6testmvnlatest.therules-0.0.2.jar
            drools6testmvnlatest.therules-0.0.2.jar.sha1
            drools6testmvnlatest.therules-0.0.2.pom
            drools6testmvnlatest.therules-0.0.2.pom.sha1
            _remote.repositories
{code}

h6. Workaround Option2
Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.

h6. Workaround Option3
Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven 
{code}
D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
{code}

This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
{code}
D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
????drools6testmvnlatest.therules
    ?   maven-metadata-local.xml
    ?
    ????0.0.2
            drools6testmvnlatest.therules-0.0.2.jar
            drools6testmvnlatest.therules-0.0.2.pom
            _remote.repositories
{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 issues at jboss.org  Thu Jan 30 14:25:30 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 30 Jan 2014 14:25:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with
 kieServices.newKieContainer() with LATEST or RELEASE instead of explicit
 version number (eg: 0.0.1) on a application where the KIE module Rule
 artifact project kjar has been locally-installed from remote Maven
 repository.
In-Reply-To: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530799.1391109809000.23883.1391109930042@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-419:
----------------------------------

    Attachment: 20140130.drools6testmvnlatest.zip


attached project zip file
                
> "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-419
>                 URL: https://issues.jboss.org/browse/DROOLS-419
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933
>            Reporter: Matteo Mortari
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: 20140130.drools6testmvnlatest.zip
>
>
> Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , I mean that before launching Application, I performed 
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> h5. Disclaimer
> I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.
> h5. DETAILS
> Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .
> Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
> {code:title=App.java}
> public static void main( String[] args ) {
> 	KieServices kieServices = KieServices.Factory.get();
> 	ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
> 	KieContainer kContainer = kieServices.newKieContainer( releaseId );
> 	KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
> 	kieBaseConf.setOption( EventProcessingOption.STREAM );
> 	KieBase kBase = kContainer.newKieBase(kieBaseConf);
> 	for ( KiePackage a : kBase.getKiePackages()) {
> 			for (Rule r : a.getRules()) {
> 				logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
> 			}
> 	}
> }
> {code}
> The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> Execution of
> {code}
> java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
> {code}
> Would generate the following stack trace
> {code}
> Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
>         at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
>         at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
> {code}
> Same for LATEST as launch parameter.
> But fixed version, eg: 0.0.2 as launch parameter, will work.
> {code}
> D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
> 2014-01-30 19:24:12,128 [main] INFO  org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
> 2014-01-30 19:24:12,440 [main] INFO  com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
> {code}
> Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h5. WORKAROUND
> The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
> h6. Workaround Option 1
> Do 'fake' a pom.xml with the dependency, something similar to:
> {code}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>com.acme</groupId>
>   <artifactId>fakepom</artifactId>
>   <version>0.0.1</version>
>   <packaging>jar</packaging>
>   <dependencies>
>     <dependency>
>       <groupId>com.acme</groupId>
>       <artifactId>drools6testmvnlatest.therules</artifactId>
>       <version>RELEASE</version>
>     </dependency>
>   </dependencies>
>   
> </project>
> {code}
> And then launch maven in the same directory of this 'fake' pom.xml with the following command:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline 
> {code}
> This usually generate the 'maven-metadata-local' file in the local .m2 repo:
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-local.xml
>     ?   maven-metadata-local.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h6. Workaround Option2
> Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.
> h6. Workaround Option3
> Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven 
> {code}
> D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
> {code}
> This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-local.xml
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.pom
>             _remote.repositories
> {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 issues at jboss.org  Thu Jan 30 14:25:29 2014
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 30 Jan 2014 14:25:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with
 kieServices.newKieContainer() with LATEST or RELEASE instead of explicit
 version number (eg: 0.0.1) on a application where the KIE module Rule
 artifact project kjar has been locally-installed from remote Maven
 repository.
In-Reply-To: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530799.1391109809000.23879.1391109929636@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-419:
----------------------------------

    Priority: Minor  (was: Major)

    
> "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-419
>                 URL: https://issues.jboss.org/browse/DROOLS-419
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933
>            Reporter: Matteo Mortari
>            Assignee: Mark Proctor
>            Priority: Minor
>         Attachments: 20140130.drools6testmvnlatest.zip
>
>
> Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , I mean that before launching Application, I performed 
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> h5. Disclaimer
> I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.
> h5. DETAILS
> Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .
> Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
> {code:title=App.java}
> public static void main( String[] args ) {
> 	KieServices kieServices = KieServices.Factory.get();
> 	ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
> 	KieContainer kContainer = kieServices.newKieContainer( releaseId );
> 	KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
> 	kieBaseConf.setOption( EventProcessingOption.STREAM );
> 	KieBase kBase = kContainer.newKieBase(kieBaseConf);
> 	for ( KiePackage a : kBase.getKiePackages()) {
> 			for (Rule r : a.getRules()) {
> 				logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
> 			}
> 	}
> }
> {code}
> The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> Execution of
> {code}
> java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
> {code}
> Would generate the following stack trace
> {code}
> Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
>         at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
>         at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
> {code}
> Same for LATEST as launch parameter.
> But fixed version, eg: 0.0.2 as launch parameter, will work.
> {code}
> D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
> 2014-01-30 19:24:12,128 [main] INFO  org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
> 2014-01-30 19:24:12,440 [main] INFO  com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
> {code}
> Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h5. WORKAROUND
> The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
> h6. Workaround Option 1
> Do 'fake' a pom.xml with the dependency, something similar to:
> {code}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>com.acme</groupId>
>   <artifactId>fakepom</artifactId>
>   <version>0.0.1</version>
>   <packaging>jar</packaging>
>   <dependencies>
>     <dependency>
>       <groupId>com.acme</groupId>
>       <artifactId>drools6testmvnlatest.therules</artifactId>
>       <version>RELEASE</version>
>     </dependency>
>   </dependencies>
>   
> </project>
> {code}
> And then launch maven in the same directory of this 'fake' pom.xml with the following command:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline 
> {code}
> This usually generate the 'maven-metadata-local' file in the local .m2 repo:
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-local.xml
>     ?   maven-metadata-local.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h6. Workaround Option2
> Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.
> h6. Workaround Option3
> Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven 
> {code}
> D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
> {code}
> This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-local.xml
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.pom
>             _remote.repositories
> {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 issues at jboss.org  Thu Jan 30 14:31:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 30 Jan 2014 14:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554000.23892.1391110288831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940302#comment-12940302 ] 

Scott Marlow commented on WFLY-2841:
------------------------------------

I tried setting wildfly.jpa.twophasebootstrap + jboss.as.jpa.classtransformer to false but neither helped.

{quote}
New missing/unsatisfied dependencies:
      service jboss.naming.context.java.module."wfds-1.0-SNAPSHOT"."wfds-1.0-SNAPSHOT".env.MyDS (missing) dependents: [service jboss.persistenceunit."wfds-1.0-SNAPSHOT.war#wfdsPU"] 
{quote}
                
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
>                 Key: WFLY-2841
>                 URL: https://issues.jboss.org/browse/WFLY-2841
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:43:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 30 Jan 2014 14:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks
 fails repeatably with DefaultTimeScheduler
In-Reply-To: <JIRA.12530803.1391110929174@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530803.1391110929174@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530803.1391110929174.23914.1391111008828@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1786:
-----------------------------------------

             Summary: TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler
                 Key: JGRP-1786
                 URL: https://issues.jboss.org/browse/JGRP-1786
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: RHEL 5 x86_64
Windows x86_64
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban


The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute

Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.



 


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:53:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 30 Jan 2014 14:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks
 fails repeatably with DefaultTimeScheduler
In-Reply-To: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530803.1391110929000.23945.1391111608729@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940308#comment-12940308 ] 

Richard Achmatowicz commented on JGRP-1786:
-------------------------------------------

This test fails repeatably on RHEL5 and Windows. See these test case runs for examples of the failure:

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-JGroups/job/JGroups-rachmato-Win/
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-JGroups/job/JGroups-rachamto-RHEL/

Any questions on how to access these machines or run the testsuites locally, just ping me.
 
                
> TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1786
>                 URL: https://issues.jboss.org/browse/JGRP-1786
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL 5 x86_64
> Windows x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:55:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 30 Jan 2014 14:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks
 fails repeatably with DefaultTimeScheduler
In-Reply-To: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530803.1391110929000.23948.1391111728629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940309#comment-12940309 ] 

Richard Achmatowicz commented on JGRP-1786:
-------------------------------------------

One note: I am logging bugs which are repeatable and occur across multiple platforms only, to minimize the number of issues logged.
 
                
> TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1786
>                 URL: https://issues.jboss.org/browse/JGRP-1786
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL 5 x86_64
> Windows x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:57:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 30 Jan 2014 14:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks
 fails repeatably with DefaultTimeScheduler
In-Reply-To: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530803.1391110929000.23950.1391111848520@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1786:
--------------------------------------

    Description: 
The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute

Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.

The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.

 


  was:
The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute

Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.



 



    
> TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1786
>                 URL: https://issues.jboss.org/browse/JGRP-1786
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL 5 x86_64
> Windows x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 14:59:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 30 Jan 2014 14:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1786) TimeSchedulerTest.test2Tasks
 fails repeatably with DefaultTimeScheduler
In-Reply-To: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530803.1391110929000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530803.1391110929000.23955.1391111968802@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940309#comment-12940309 ] 

Richard Achmatowicz edited comment on JGRP-1786 at 1/30/14 2:58 PM:
--------------------------------------------------------------------

Note 1: I am logging bugs which are repeatable and occur across multiple platforms only, to minimize the number of issues logged.
Note 2: There is a limit to the amount of root cause analysis I can do on these bugs. I'll try my best but ... 
                
      was (Author: rachmato):
    One note: I am logging bugs which are repeatable and occur across multiple platforms only, to minimize the number of issues logged.
 
                  
> TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1786
>                 URL: https://issues.jboss.org/browse/JGRP-1786
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: RHEL 5 x86_64
> Windows x86_64
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 15:03:29 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 30 Jan 2014 15:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2849) Upgrade jboss-remote-naming
 to 2.0.0 Final or later
In-Reply-To: <JIRA.12530807.1391112160761@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530807.1391112160761@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530807.1391112160761.23964.1391112209034@jira02.app.mwc.hst.phx2.redhat.com>

Brad Maxwell created WFLY-2849:
----------------------------------

             Summary: Upgrade jboss-remote-naming to 2.0.0 Final or later
                 Key: WFLY-2849
                 URL: https://issues.jboss.org/browse/WFLY-2849
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: 8.0.0.CR1
            Reporter: Brad Maxwell
            Assignee: Eduardo Martins


Upgrade jboss-remote-naming to 2.0.0 Final or later to resolve linked 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 issues at jboss.org  Thu Jan 30 15:03:29 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 30 Jan 2014 15:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2849) Upgrade jboss-remote-naming
 to 2.0.0 Final or later
In-Reply-To: <JIRA.12530807.1391112160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530807.1391112160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530807.1391112160000.23967.1391112209263@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-2849:
-------------------------------

    Git Pull Request:   (was: https://github.com/jbossas/jboss-remote-naming/commit/b3c34f54b350f220b480187d89771c593315bcf3)

    
> Upgrade jboss-remote-naming to 2.0.0 Final or later
> ---------------------------------------------------
>
>                 Key: WFLY-2849
>                 URL: https://issues.jboss.org/browse/WFLY-2849
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Eduardo Martins
>
> Upgrade jboss-remote-naming to 2.0.0 Final or later to resolve linked 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 issues at jboss.org  Thu Jan 30 15:05:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 30 Jan 2014 15:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.23969.1391112328722@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940311#comment-12940311 ] 

Brad Maxwell commented on WFLY-2839:
------------------------------------

Resolved in JBoss Remote Naming 2.0.0 Final
                
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 15:05:28 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 30 Jan 2014 15:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.23972.1391112328909@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell resolved WFLY-2839.
--------------------------------

    Resolution: Done

    
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 15:05:29 2014
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Thu, 30 Jan 2014 15:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2839) Remote Naming communication
 exception should be thrown on ConnectException
In-Reply-To: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530687.1391029853000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530687.1391029853000.23973.1391112329016@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940311#comment-12940311 ] 

Brad Maxwell edited comment on WFLY-2839 at 1/30/14 3:05 PM:
-------------------------------------------------------------

Resolved in JBoss Remote Naming 2.0.0 Final & Wildfly fixed version will be via https://issues.jboss.org/browse/WFLY-2849
                
      was (Author: bmaxwell):
    Resolved in JBoss Remote Naming 2.0.0 Final
                  
> Remote Naming communication exception should be thrown on ConnectException
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2839
>                 URL: https://issues.jboss.org/browse/WFLY-2839
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> Remote Naming communication exception should be thrown on ConnectException, a remoting bug fix showed that a ConnectException can be thrown to remoting and we should throw this as a CommunicationException instead of generic NamingException.  This is related to WFLY-2198

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 15:21:29 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 30 Jan 2014 15:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2745) Typo in jboss-cli help message
In-Reply-To: <JIRA.12529155.1389563386000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529155.1389563386000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529155.1389563386000.24033.1391113289080@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2745.
-------------------------------------

    Resolution: Done


Fixed. Thanks!
                
> Typo in jboss-cli help message
> ------------------------------
>
>                 Key: WFLY-2745
>                 URL: https://issues.jboss.org/browse/WFLY-2745
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: 8.0.0.CR1
>            Reporter: Arun Gupta
>            Assignee: Alexey Loubyansky
>            Priority: Trivial
>             Fix For: 8.0.0.Final
>
>
> jboss-cli -h shows the following help message for --controller.
> The default controller host is localhost and the port is 9999.
> The port number should be 9990 instead of 9999.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 15:55:29 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 30 Jan 2014 15:55:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554000.24110.1391115329316@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2841:
-------------------------------

    Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001541.html

    
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
>                 Key: WFLY-2841
>                 URL: https://issues.jboss.org/browse/WFLY-2841
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 15:57:28 2014
From: issues at jboss.org (Mike Rodriguez (JIRA))
Date: Thu, 30 Jan 2014 15:57:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-420) Incorrect resolution of
 global symbols in LHS rule constraint (Java dialect)
In-Reply-To: <JIRA.12530837.1391115433073@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530837.1391115433073@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530837.1391115433073.24119.1391115448960@jira02.app.mwc.hst.phx2.redhat.com>

Mike Rodriguez created DROOLS-420:
-------------------------------------

             Summary: Incorrect resolution of global symbols in LHS rule constraint (Java dialect)
                 Key: DROOLS-420
                 URL: https://issues.jboss.org/browse/DROOLS-420
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mike Rodriguez
            Assignee: Mark Proctor
            Priority: Minor


As described @ [http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-in-LHS-rule-constraint-Java-dialect-tp4027921.html].

I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals.   

We have rule constraints that access globals in a DRL; like this:   
{code}some.classpath.package2.MyType ( global_instance.invoke(this) == true ) {code}

I have {code}some.classpath.package.SomeType global_instance;{code} declared at the top of the DRL, but it doesn't seem to be interpreting it as a global in the rule's restriction. 

So, putting this into context within, I have a DRL such as: 

package my.package.example; 

global some.classpath.package.SomeType global_instance; 
{code}

rule "Example rule" 
when 
   some.classpath.package2.MyType ( global_instance.invoke(this) == true ) 
then 
   // do something 
end 

{code}

I am getting an error from the package builder originating from the "Example rule" specifying something like: 
"can't find method MyType.global_instance()" 

Once, again this did work in 5.5.0.Final, but in 5.6.0.Final I am getting a failure trying to build the knowledge package. 
It looks to me like the {{global_instance}} symbol is not being recognized as a global in the DRL and is trying to be 
resolved as a method of the MyType class.   
So I guess it would be trying to do a "MyType.global_instance().invoke(this)" or something. 

The intent is that {{global_instance}} will be set for a session with an immutable function-type of class 
(invoke is an instance method though; not static).  The rule restriction uses this function/predicate to determine if some 
complex criteria is true for `this` MyType instance. 

I would appreciate any insight into what the issue might be.  I haven't been able to find any threads out there on a similar 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 issues at jboss.org  Thu Jan 30 15:59:28 2014
From: issues at jboss.org (Mike Rodriguez (JIRA))
Date: Thu, 30 Jan 2014 15:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-420) Incorrect resolution of
 global symbols in LHS rule constraint (Java dialect)
In-Reply-To: <JIRA.12530837.1391115433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530837.1391115433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530837.1391115433000.24122.1391115568509@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940336#comment-12940336 ] 

Mike Rodriguez commented on DROOLS-420:
---------------------------------------

This was discovered when upgrading to 5.6.0.Final from 5.5.0.Final.  I was not seeing a 5.6.0.Final affects version when making this Jira.

According to [this|http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-in-LHS-rule-constraint-Java-dialect-tp4027921p4027929.html], it affects Drools 6.x too.
                
> Incorrect resolution of global symbols in LHS rule constraint (Java dialect)
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-420
>                 URL: https://issues.jboss.org/browse/DROOLS-420
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mike Rodriguez
>            Assignee: Mark Proctor
>            Priority: Minor
>
> As described @ [http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-in-LHS-rule-constraint-Java-dialect-tp4027921.html].
> I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals.   
> We have rule constraints that access globals in a DRL; like this:   
> {code}some.classpath.package2.MyType ( global_instance.invoke(this) == true ) {code}
> I have {code}some.classpath.package.SomeType global_instance;{code} declared at the top of the DRL, but it doesn't seem to be interpreting it as a global in the rule's restriction. 
> So, putting this into context within, I have a DRL such as: 
> package my.package.example; 
> global some.classpath.package.SomeType global_instance; 
> {code}
> rule "Example rule" 
> when 
>    some.classpath.package2.MyType ( global_instance.invoke(this) == true ) 
> then 
>    // do something 
> end 
> {code}
> I am getting an error from the package builder originating from the "Example rule" specifying something like: 
> "can't find method MyType.global_instance()" 
> Once, again this did work in 5.5.0.Final, but in 5.6.0.Final I am getting a failure trying to build the knowledge package. 
> It looks to me like the {{global_instance}} symbol is not being recognized as a global in the DRL and is trying to be 
> resolved as a method of the MyType class.   
> So I guess it would be trying to do a "MyType.global_instance().invoke(this)" or something. 
> The intent is that {{global_instance}} will be set for a session with an immutable function-type of class 
> (invoke is an instance method though; not static).  The rule restriction uses this function/predicate to determine if some 
> complex criteria is true for `this` MyType instance. 
> I would appreciate any insight into what the issue might be.  I haven't been able to find any threads out there on a similar 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 issues at jboss.org  Thu Jan 30 17:21:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 17:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2831) Method
 Utils.getSecondaryTestAddress(ManagementClient,
 boolean) doesn't strip square brackets from host IPv6 address
In-Reply-To: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530640.1391007201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530640.1391007201000.24178.1391120488573@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940347#comment-12940347 ] 

RH Bugzilla Integration commented on WFLY-2831:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1059260|https://bugzilla.redhat.com/show_bug.cgi?id=1059260] from POST to MODIFIED
                
> Method Utils.getSecondaryTestAddress(ManagementClient, boolean) doesn't strip square brackets from host IPv6 address
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2831
>                 URL: https://issues.jboss.org/browse/WFLY-2831
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The striping of square brackets around IPv6 addresses doesn't work in 
> org.jboss.as.test.integration.security.common.Utils.getSecondaryTestAddress(ManagementClient, boolean), it causes failures of AdvancedLdapLoginModuleTestCase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Thu Jan 30 18:03:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 18:03:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.24217.1391123008779@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2840:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059911

    
> @Schedule EJB Timer not using timezone when calcualting next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
> {code}
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> {code}
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> {code}
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }
> {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 issues at jboss.org  Thu Jan 30 18:05:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 30 Jan 2014 18:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2840) @Schedule EJB Timer not using
 timezone when calcualting next timeout
In-Reply-To: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530696.1391054454000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530696.1391054454000.24222.1391123128686@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2840:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059911, https://bugzilla.redhat.com/show_bug.cgi?id=1059914  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1059911)

    
> @Schedule EJB Timer not using timezone when calcualting next timeout
> --------------------------------------------------------------------
>
>                 Key: WFLY-2840
>                 URL: https://issues.jboss.org/browse/WFLY-2840
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>
> With a system running in Central Timezone, if it uses the annotation below specifying the timezone as Eastern timezone, with the hour set to the current hour.
> The timer will fire once, and it will calculate the next timeout to be in the next hour CST, where as it should take in consideration the timezone specified on @Schedule which is Eastern.  If it did, then the timer should continue to fire every minute.
> {code}
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
> {code}
> 21:53:00,006 INFO  [stdout] (EJB default - 1) ScheduleTest: nextTimeout:Wed Jan 29 22:00:00 CST 2014
> {code}
> import javax.ejb.Schedule;
> import javax.ejb.Singleton;
> import javax.ejb.Startup;
> @Startup
> @Singleton
> public class ScheduleTest {
>   @Schedule(persistent = false, timezone = "America/New_York", dayOfMonth = "*", dayOfWeek = "*", month = "*", hour = "22", minute = "*", second = "0", year = "*")
>   public void helloWorld(Timer time) {
>     System.out.println("ScheduleTest: timer:" + time.getClass().getName() + " " + time.getNextTimeout() + " " + time.getInfo());
>   }
> }
> {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 issues at jboss.org  Thu Jan 30 19:29:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 30 Jan 2014 19:29:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-254) tomcatAuthentication attribute
 on the AJP connector
In-Reply-To: <JIRA.12445093.1313755997000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445093.1313755997000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445093.1313755997000.24260.1391128169387@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940359#comment-12940359 ] 

Tomaz Cerar commented on WFLY-254:
----------------------------------

@geert.coelmont create new issue for that as beyond similar resulting behavior it has noting to do with this one
                
> tomcatAuthentication attribute on the AJP connector
> ---------------------------------------------------
>
>                 Key: WFLY-254
>                 URL: https://issues.jboss.org/browse/WFLY-254
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>         Environment: Windows Server 2003 32 bit, IIS 6, tomcat connector 1.2.28 used as an extension
>            Reporter: Brett Prucha
>            Assignee: Jean-Frederic Clere
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> In JBoss 5.1.0 I could set the tomcatAuthentication attribute of the AJP connector to false to allow IIS to handle the authentication and pass that along to JBoss. I'm wanting to upgrade to JBoss 7 but unable to set this attribute in version 7.0.0 final to make this work. This attribute is descibed in the tomcat documentation at http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.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 issues at jboss.org  Thu Jan 30 20:49:28 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 30 Jan 2014 20:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2592) A server-to-server
 communication via outbound connection is not working
In-Reply-To: <JIRA.12526575.1385838719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526575.1385838719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526575.1385838719000.24343.1391132968848@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940370#comment-12940370 ] 

David Lloyd commented on WFLY-2592:
-----------------------------------

Packet dump shows lots of retransmits - are you sure you don't have some kind of firewall issue here?  Or perhaps remoting (native) connecting to a remoting+http port?
                
> A server-to-server communication via outbound connection is not working
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2592
>                 URL: https://issues.jboss.org/browse/WFLY-2592
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>            Priority: Blocker
>              Labels: ejb, remoting
>         Attachments: networktraffic, server-client.log, server-server.log
>
>
> A ejb invocation from a SLSB is configured similar to AS7 (EAP6) to call a remote server fail in WildFly with the ERROR message " EJBCLIENT000025: No EJB receiver available for handling".
> The logfiles of client(server) and remote-server are attached, also a WireShark dump of the related network traffic.
> A standalone client at the same machine is able to call the remote 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 issues at jboss.org  Thu Jan 30 21:03:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 30 Jan 2014 21:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2522) Error when invoking @Remove
 method for stateful bean in transaction
In-Reply-To: <JIRA.12525373.1384610529000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525373.1384610529000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525373.1384610529000.24351.1391133809412@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924676#comment-12924676 ] 

David Lloyd edited comment on WFLY-2522 at 1/30/14 9:02 PM:
------------------------------------------------------------

Yes. the EJB should normally be removed without exception. 

Following is the stacktrace from WildFire server: 

{noformat}
23:34:17,262 ERROR [org.jboss.as.ejb3] (EJB default - 4) javax.ejb.EJBTransactionRolledbackException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
23:34:17,262 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 4) JBAS014134: EJB Invocation failed on component StatefulSb for method public abstract void com.jboss.bug.StatefulSbLocal.removeMethod(): javax.ejb.EJBTransactionRolledbackException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java: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.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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 com.jboss.bug.StatefulSbLocal$$$view2.removeMethod(Unknown Source) [JBossTxSyncError.jar:]
	at com.jboss.bug.OldEjb2.callThirdSession(OldEjb2.java:40) [JBossTxSyncError.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.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:45) [wildfly-ee-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:401) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:246) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at com.sun.proxy.$Proxy43.callThirdSession(Unknown Source)
	at com.jboss.bug.EmployeeBean.ejbStore(EmployeeBean.java:239) [JBossTxSyncError.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:196) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.store(EntityBeanComponentInstance.java:181) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:191) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)
	at com.jboss.bug.OldEjb.doSomethingInBmtTx(OldEjb.java:82) [JBossTxSyncError.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.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:45) [wildfly-ee-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:163) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:290) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	... 219 more

23:34:17,277 ERROR [stderr] (EJB default - 4) javax.ejb.EJBTransactionRolledbackException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING

23:34:17,277 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.StatefulSbLocal$$$view2.removeMethod(Unknown Source)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb2.callThirdSession(OldEjb2.java:40)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:401)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:246)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at com.sun.proxy.$Proxy43.callThirdSession(Unknown Source)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.EmployeeBean.ejbStore(EmployeeBean.java:239)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:196)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.store(EntityBeanComponentInstance.java:181)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:191)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb.doSomethingInBmtTx(OldEjb.java:82)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at java.lang.Thread.run(Thread.java:744)

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

23:34:17,317 ERROR [stderr] (EJB default - 4) Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:163)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:55)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:290)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	... 219 more

23:34:17,323 ERROR [stderr] (EJB default - 4) javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.

23:34:17,323 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1182)

23:34:17,323 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)

23:34:17,323 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb.doSomethingInBmtTx(OldEjb.java:82)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.lang.Thread.run(Thread.java:744)

23:34:17,336 ERROR [stderr] (EJB default - 4) 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

23:34:17,336 ERROR [stderr] (EJB default - 4) Caused by: java.lang.Throwable: setRollbackOnly called from:

23:34:17,336 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:314)

23:34:17,336 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.setRollbackOnly(CMTTxInterceptor.java:387)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:169)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.StatefulSbLocal$$$view2.removeMethod(Unknown Source)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb2.callThirdSession(OldEjb2.java:40)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:401)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:246)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at com.sun.proxy.$Proxy43.callThirdSession(Unknown Source)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.EmployeeBean.ejbStore(EmployeeBean.java:239)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:196)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.store(EntityBeanComponentInstance.java:181)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:191)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)

23:34:17,359 ERROR [stderr] (EJB default - 4) 	... 79 more
{noformat}
                
      was (Author: noelaa5):
    Yes. the EJB should normally be removed without exception. 

Following is the stacktrace from WildFire server: 

23:34:17,262 ERROR [org.jboss.as.ejb3] (EJB default - 4) javax.ejb.EJBTransactionRolledbackException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
23:34:17,262 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 4) JBAS014134: EJB Invocation failed on component StatefulSb for method public abstract void com.jboss.bug.StatefulSbLocal.removeMethod(): javax.ejb.EJBTransactionRolledbackException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java: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.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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 com.jboss.bug.StatefulSbLocal$$$view2.removeMethod(Unknown Source) [JBossTxSyncError.jar:]
	at com.jboss.bug.OldEjb2.callThirdSession(OldEjb2.java:40) [JBossTxSyncError.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.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:45) [wildfly-ee-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:401) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:246) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-2.0.0.Beta3.jar:2.0.0.Beta3]
	at com.sun.proxy.$Proxy43.callThirdSession(Unknown Source)
	at com.jboss.bug.EmployeeBean.ejbStore(EmployeeBean.java:239) [JBossTxSyncError.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:196) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.store(EntityBeanComponentInstance.java:181) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:191) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)
	at com.jboss.bug.OldEjb.doSomethingInBmtTx(OldEjb.java:82) [JBossTxSyncError.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
	at org.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:45) [wildfly-ee-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	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.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:163) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:290) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	... 219 more

23:34:17,277 ERROR [stderr] (EJB default - 4) javax.ejb.EJBTransactionRolledbackException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING

23:34:17,277 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,278 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,279 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,280 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,281 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,282 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,283 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.StatefulSbLocal$$$view2.removeMethod(Unknown Source)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb2.callThirdSession(OldEjb2.java:40)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,284 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,285 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,286 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,287 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,288 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,289 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)

23:34:17,290 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:401)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,291 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,292 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,293 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,294 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,295 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:246)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

23:34:17,296 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)

23:34:17,297 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)

23:34:17,298 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at com.sun.proxy.$Proxy43.callThirdSession(Unknown Source)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.EmployeeBean.ejbStore(EmployeeBean.java:239)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,299 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,300 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,301 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:196)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.store(EntityBeanComponentInstance.java:181)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:191)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)

23:34:17,302 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)

23:34:17,303 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb.doSomethingInBmtTx(OldEjb.java:82)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,304 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,305 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,306 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,307 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,308 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,309 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,310 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,311 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,312 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,313 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,314 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)

23:34:17,315 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

23:34:17,316 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at java.lang.Thread.run(Thread.java:744)

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

23:34:17,317 ERROR [stderr] (EJB default - 4) Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)

23:34:17,317 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:163)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:55)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39)

23:34:17,318 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:290)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)

23:34:17,319 ERROR [stderr] (EJB default - 4) 	... 219 more

23:34:17,323 ERROR [stderr] (EJB default - 4) javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.

23:34:17,323 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1182)

23:34:17,323 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)

23:34:17,323 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:173)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb.doSomethingInBmtTx(OldEjb.java:82)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,324 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,325 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,326 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,327 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:104)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:56)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,328 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,329 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,330 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,331 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,332 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,333 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)

23:34:17,334 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

23:34:17,335 ERROR [stderr] (EJB default - 4) 	at java.lang.Thread.run(Thread.java:744)

23:34:17,336 ERROR [stderr] (EJB default - 4) 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)

23:34:17,336 ERROR [stderr] (EJB default - 4) Caused by: java.lang.Throwable: setRollbackOnly called from:

23:34:17,336 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:314)

23:34:17,336 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.setRollbackOnly(CMTTxInterceptor.java:387)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:169)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,337 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,338 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,339 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,340 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,341 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.StatefulSbLocal$$$view2.removeMethod(Unknown Source)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.OldEjb2.callThirdSession(OldEjb2.java:40)

23:34:17,342 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,343 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130)

23:34:17,344 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,345 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84)

23:34:17,346 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,347 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:401)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)

23:34:17,348 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,349 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:65)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,350 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,351 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)

23:34:17,352 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:246)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)

23:34:17,353 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

23:34:17,354 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at com.sun.proxy.$Proxy43.callThirdSession(Unknown Source)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at com.jboss.bug.EmployeeBean.ejbStore(EmployeeBean.java:239)

23:34:17,355 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at java.lang.reflect.Method.invoke(Method.java:606)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

23:34:17,356 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

23:34:17,357 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:196)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.store(EntityBeanComponentInstance.java:181)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:191)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)

23:34:17,358 ERROR [stderr] (EJB default - 4) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)

23:34:17,359 ERROR [stderr] (EJB default - 4) 	... 79 more


                  
> Error when invoking @Remove method for stateful bean in transaction
> -------------------------------------------------------------------
>
>                 Key: WFLY-2522
>                 URL: https://issues.jboss.org/browse/WFLY-2522
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: noel a.a
>            Assignee: David Lloyd
>            Priority: Blocker
>
> I'm invoking method annotated with @Remove
> {code}
> @Remove
> public void remove() {
> ...
> {code}
> On invocation inside active transaction I'm getting following error :
> {noformat}
> Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:374)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:351)
> at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:165) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:57) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:283) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> 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.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> 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:200) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> ... 140 more
> {noformat}
> EJB Spec paragraphe 4.6.4 states:
> {quote}
> If a session bean instance is participating in a transaction, it is an error for a client to invoke the remove method on the session object?s home or component interface object. The container must detect such an attempt and throw the javax.ejb.RemoveException to the client. The container should not mark the client?s transaction for rollback, thus allowing the client to recover. Note that this restriction only applies to the remove method on the session object?s home or component interface, not to the invocation of @Remove methods.
> {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 issues at jboss.org  Thu Jan 30 21:37:28 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 30 Jan 2014 21:37:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.24359.1391135848860@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940373#comment-12940373 ] 

David Lloyd commented on WFLY-2809:
-----------------------------------

Seems reasonable to me.
                
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: Stefan Guilhen
>            Priority: Blocker
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Thu Jan 30 21:37:29 2014
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 30 Jan 2014 21:37:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.24362.1391135849039@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2809:
------------------------------

    Fix Version/s: 8.0.0.Final

    
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: Stefan Guilhen
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Fri Jan 31 03:09:28 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 03:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-420) Incorrect resolution of
 global symbols in LHS rule constraint (Java dialect)
In-Reply-To: <JIRA.12530837.1391115433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530837.1391115433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530837.1391115433000.24662.1391155768822@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-420:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Incorrect resolution of global symbols in LHS rule constraint (Java dialect)
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-420
>                 URL: https://issues.jboss.org/browse/DROOLS-420
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mike Rodriguez
>            Assignee: Mario Fusco
>            Priority: Minor
>
> As described @ [http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-in-LHS-rule-constraint-Java-dialect-tp4027921.html].
> I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals.   
> We have rule constraints that access globals in a DRL; like this:   
> {code}some.classpath.package2.MyType ( global_instance.invoke(this) == true ) {code}
> I have {code}some.classpath.package.SomeType global_instance;{code} declared at the top of the DRL, but it doesn't seem to be interpreting it as a global in the rule's restriction. 
> So, putting this into context within, I have a DRL such as: 
> package my.package.example; 
> global some.classpath.package.SomeType global_instance; 
> {code}
> rule "Example rule" 
> when 
>    some.classpath.package2.MyType ( global_instance.invoke(this) == true ) 
> then 
>    // do something 
> end 
> {code}
> I am getting an error from the package builder originating from the "Example rule" specifying something like: 
> "can't find method MyType.global_instance()" 
> Once, again this did work in 5.5.0.Final, but in 5.6.0.Final I am getting a failure trying to build the knowledge package. 
> It looks to me like the {{global_instance}} symbol is not being recognized as a global in the DRL and is trying to be 
> resolved as a method of the MyType class.   
> So I guess it would be trying to do a "MyType.global_instance().invoke(this)" or something. 
> The intent is that {{global_instance}} will be set for a session with an immutable function-type of class 
> (invoke is an instance method though; not static).  The rule restriction uses this function/predicate to determine if some 
> complex criteria is true for `this` MyType instance. 
> I would appreciate any insight into what the issue might be.  I haven't been able to find any threads out there on a similar 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 issues at jboss.org  Fri Jan 31 03:09:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 03:09:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-420) Incorrect resolution of
 global symbols in LHS rule constraint (Java dialect)
In-Reply-To: <JIRA.12530837.1391115433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530837.1391115433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530837.1391115433000.24665.1391155769189@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-420.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done

    
> Incorrect resolution of global symbols in LHS rule constraint (Java dialect)
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-420
>                 URL: https://issues.jboss.org/browse/DROOLS-420
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mike Rodriguez
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 6.1.0.Beta1
>
>
> As described @ [http://drools.46999.n3.nabble.com/Incorrect-resolution-of-global-symbols-in-LHS-rule-constraint-Java-dialect-tp4027921.html].
> I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals.   
> We have rule constraints that access globals in a DRL; like this:   
> {code}some.classpath.package2.MyType ( global_instance.invoke(this) == true ) {code}
> I have {code}some.classpath.package.SomeType global_instance;{code} declared at the top of the DRL, but it doesn't seem to be interpreting it as a global in the rule's restriction. 
> So, putting this into context within, I have a DRL such as: 
> package my.package.example; 
> global some.classpath.package.SomeType global_instance; 
> {code}
> rule "Example rule" 
> when 
>    some.classpath.package2.MyType ( global_instance.invoke(this) == true ) 
> then 
>    // do something 
> end 
> {code}
> I am getting an error from the package builder originating from the "Example rule" specifying something like: 
> "can't find method MyType.global_instance()" 
> Once, again this did work in 5.5.0.Final, but in 5.6.0.Final I am getting a failure trying to build the knowledge package. 
> It looks to me like the {{global_instance}} symbol is not being recognized as a global in the DRL and is trying to be 
> resolved as a method of the MyType class.   
> So I guess it would be trying to do a "MyType.global_instance().invoke(this)" or something. 
> The intent is that {{global_instance}} will be set for a session with an immutable function-type of class 
> (invoke is an instance method though; not static).  The rule restriction uses this function/predicate to determine if some 
> complex criteria is true for `this` MyType instance. 
> I would appreciate any insight into what the issue might be.  I haven't been able to find any threads out there on a similar 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 issues at jboss.org  Fri Jan 31 03:19:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 03:19:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-89) LogContext's root logger is
 not created with a strong child hash map when strong=true
In-Reply-To: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525357.1384544962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525357.1384544962000.24670.1391156369052@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940403#comment-12940403 ] 

RH Bugzilla Integration commented on LOGMGR-89:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1031221|https://bugzilla.redhat.com/show_bug.cgi?id=1031221] from ON_QA to VERIFIED
                
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-89
>                 URL: https://issues.jboss.org/browse/LOGMGR-89
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
>            Reporter: Kyle Lape
>            Assignee: David Lloyd
>             Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
>   <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
>     <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
>     <param name="MaxFileSize" value="2MB"/>
>     <param name="MaxBackupIndex" value="5"/>
>     <param name="Append" value="true"/>
>     <layout class="org.apache.log4j.PatternLayout">
>       <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
>     </layout>
>   </appender>
>   <logger name="com.redhat" additivity="false">
>     <level value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP_MDB"/>
>   </logger>
>   <root>
>     <priority value="TRACE"/>
>     <appender-ref ref="SAMPLE_APP"/>
>   </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used.  One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO  [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {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 issues at jboss.org  Fri Jan 31 03:37:29 2014
From: issues at jboss.org (Geert Coelmont (JIRA))
Date: Fri, 31 Jan 2014 03:37:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2850) AJP connector with external
	authentication
In-Reply-To: <JIRA.12530843.1391157375854@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530843.1391157375854@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530843.1391157375854.24693.1391157449585@jira02.app.mwc.hst.phx2.redhat.com>

Geert Coelmont created WFLY-2850:
------------------------------------

             Summary: AJP connector with external authentication
                 Key: WFLY-2850
                 URL: https://issues.jboss.org/browse/WFLY-2850
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
            Reporter: Geert Coelmont
            Assignee: Stuart Douglas
            Priority: Critical


Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along.
A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see.
For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 04:33:28 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 31 Jan 2014 04:33:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2805) Fix the classpath resolution
 in jconsole.sh (and .bat)
In-Reply-To: <JIRA.12530217.1390493571000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530217.1390493571000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530217.1390493571000.24986.1391160808876@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2805.
---------------------------------------

    Resolution: Done


This got merged already.
                
> Fix the classpath resolution in jconsole.sh (and .bat)
> ------------------------------------------------------
>
>                 Key: WFLY-2805
>                 URL: https://issues.jboss.org/browse/WFLY-2805
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> The jconsole scripts use a some hardcoded module names and the module path to resolve the classpath. This however might not work with a patched instance, since modules get invalidated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 04:33:29 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 31 Jan 2014 04:33:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.24994.1391160809423@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber reassigned WFLY-2785:
-----------------------------------------

    Assignee: Aleksandar Kostadinov  (was: Emanuel Muckenhuber)


Once your PR is merged, you can resolve this issue. Thanks
                
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: addressing, domain, socket
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 04:49:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 04:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-388) Inconsistent behavior of
 "contains" operator
In-Reply-To: <JIRA.12528448.1388291377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528448.1388291377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528448.1388291377000.25014.1391161768834@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-388:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060033

    
> Inconsistent behavior of "contains" operator
> --------------------------------------------
>
>                 Key: DROOLS-388
>                 URL: https://issues.jboss.org/browse/DROOLS-388
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>
> The compiler accepts constraints such as
> {code}
> Person( fullName contains 'Jr' )  // should be fullName.contains('Jr')
> {code}
> Interestingly, MVEL evaluates it as the string operation "contains", but 
> once the constraint is jitted it is again evaluated as a collection operator.
> That is, a rule such as:
> {code}
>   when
>     $s : String( this contains "foo" ) 
>   then
> {code}
> with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 04:49:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 04:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-388) Inconsistent behavior of
 "contains" operator
In-Reply-To: <JIRA.12528448.1388291377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528448.1388291377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528448.1388291377000.25018.1391161769027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940413#comment-12940413 ] 

RH Bugzilla Integration commented on DROOLS-388:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1060033|https://bugzilla.redhat.com/show_bug.cgi?id=1060033] from NEW to ASSIGNED
                
> Inconsistent behavior of "contains" operator
> --------------------------------------------
>
>                 Key: DROOLS-388
>                 URL: https://issues.jboss.org/browse/DROOLS-388
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>
> The compiler accepts constraints such as
> {code}
> Person( fullName contains 'Jr' )  // should be fullName.contains('Jr')
> {code}
> Interestingly, MVEL evaluates it as the string operation "contains", but 
> once the constraint is jitted it is again evaluated as a collection operator.
> That is, a rule such as:
> {code}
>   when
>     $s : String( this contains "foo" ) 
>   then
> {code}
> with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 04:57:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 04:57:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-388) Inconsistent behavior of
 "contains" operator
In-Reply-To: <JIRA.12528448.1388291377000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528448.1388291377000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528448.1388291377000.25032.1391162249057@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-388.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done

    
> Inconsistent behavior of "contains" operator
> --------------------------------------------
>
>                 Key: DROOLS-388
>                 URL: https://issues.jboss.org/browse/DROOLS-388
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 6.1.0.Beta1
>
>
> The compiler accepts constraints such as
> {code}
> Person( fullName contains 'Jr' )  // should be fullName.contains('Jr')
> {code}
> Interestingly, MVEL evaluates it as the string operation "contains", but 
> once the constraint is jitted it is again evaluated as a collection operator.
> That is, a rule such as:
> {code}
>   when
>     $s : String( this contains "foo" ) 
>   then
> {code}
> with inputs "foo1" .. "fooN" effectively fires an unpredictable number of times before starting to fail silently

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 05:09:28 2014
From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=)
Date: Fri, 31 Jan 2014 05:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.25076.1391162968765@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940417#comment-12940417 ] 

P?tr Andreev commented on WFLY-2739:
------------------------------------

Pull Request: https://github.com/wildfly/wildfly/pull/5828
                
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 05:19:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 05:19:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2672) Additional debug logging for
 LDAP based group loading.
In-Reply-To: <JIRA.12528256.1387475787000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528256.1387475787000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528256.1387475787000.25094.1391163570058@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940420#comment-12940420 ] 

RH Bugzilla Integration commented on WFLY-2672:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> changed the Status of [bug 1044772|https://bugzilla.redhat.com/show_bug.cgi?id=1044772] from POST to MODIFIED
                
> Additional debug logging for LDAP based group loading.
> ------------------------------------------------------
>
>                 Key: WFLY-2672
>                 URL: https://issues.jboss.org/browse/WFLY-2672
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.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 issues at jboss.org  Fri Jan 31 07:19:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2456) Using add-user.bat for
 initial admin user results in "JBAS015234: No mgmt-groups.properties files
 found"
In-Reply-To: <JIRA.12518197.1383793123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518197.1383793123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518197.1383793123000.25335.1391170768701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2456:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 9.0.0.CR1)

    
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2456
>                 URL: https://issues.jboss.org/browse/WFLY-2456
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7, 32-bit, jdk1.7.0_45
>            Reporter: John Lusk
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> Just getting started w/Wildfly after a long absence from Java.  Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
>  a) Management User (mgmt-users.properties)
>  b) Application User (application-users.properties)
> (a): a
>  * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 07:19:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:19:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-566) Using pre-digested passwords,
 having all installations with the same realm could reduce the
 effectiveness
In-Reply-To: <JIRA.12447700.1316777875000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447700.1316777875000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447700.1316777875000.25339.1391170768981@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-566:
----------------------------------

    Fix Version/s: 8.0.0.Final
                       (was: 9.0.0.CR1)

    
> Using pre-digested passwords, having all installations with the same realm could reduce the effectiveness
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-566
>                 URL: https://issues.jboss.org/browse/WFLY-566
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Realm_Management
>             Fix For: 8.0.0.Final
>
>
> Can we generate a name of first boot?  Possibly even separate the internal name use to link from the realm to the name presented to the end 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 issues at jboss.org  Fri Jan 31 07:31:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2489) Replace add-user example
 image with something not running as root.
In-Reply-To: <JIRA.12524818.1384191715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524818.1384191715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524818.1384191715000.25354.1391171488955@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2489:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: 8.0.0.Final)

    
> Replace add-user example image with something not running as root.
> ------------------------------------------------------------------
>
>                 Key: WFLY-2489
>                 URL: https://issues.jboss.org/browse/WFLY-2489
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.1.Final
>
>
> Where no users are defined we show a web page with an example using the add user utility - would be a good idea to not be encouraging running as root.
> In addition to this some of the prompts have evolved anyway e.g. no longer a need to specify the realm 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 issues at jboss.org  Fri Jan 31 07:31:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2440) Thread pool
 AccessControlContext Propagation
In-Reply-To: <JIRA.12518017.1383655122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12518017.1383655122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12518017.1383655122000.25356.1391171489095@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2440:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Thread pool AccessControlContext Propagation
> --------------------------------------------
>
>                 Key: WFLY-2440
>                 URL: https://issues.jboss.org/browse/WFLY-2440
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> A decision was made within Java that newly created threads should inherit the access control context of their creator.  
> In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have.
> Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread.
> This may affect components outside of WildFly but I am raising it here as a top level task.
> Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 07:31:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:31:29 -0500 (EST)
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.25359.1391171489328@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: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> 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
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 9.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 issues at jboss.org  Fri Jan 31 07:41:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:41:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1523) Addition of caching for
 security realms backed by ldap.
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.25393.1391172090470@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:
-----------------------------------

    Priority: Major  (was: Critical)

    
> Addition of caching for security realms backed by ldap.
> -------------------------------------------------------
>
>                 Key: WFLY-1523
>                 URL: https://issues.jboss.org/browse/WFLY-1523
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Final
>
>
> 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 issues at jboss.org  Fri Jan 31 07:45:32 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 07:45:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1197) Port the legacy jmx-console
	to AS7
In-Reply-To: <JIRA.12450210.1319471758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12450210.1319471758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12450210.1319471758000.25429.1391172332617@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1197:
-----------------------------------

    Fix Version/s: 9.0.0.CR1

    
> Port the legacy jmx-console to AS7
> ----------------------------------
>
>                 Key: WFLY-1197
>                 URL: https://issues.jboss.org/browse/WFLY-1197
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Dimitris Andreadis
>            Assignee: Darran Lofthouse
>              Labels: JMX, as7, jmx-console
>             Fix For: 9.0.0.CR1
>
>         Attachments: jmx-console.war, jmx-console.war
>
>
> I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console.
> I've ported the old console in this branch:
> https://github.com/dandreadis/jboss-as/commits/jmx-console
> It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war)
> If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default?
> The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 07:59:29 2014
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 31 Jan 2014 07:59:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2485) @Transactional not working
 correctly with @Stereotype wrt. Exception handling
In-Reply-To: <JIRA.12524772.1384175441000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524772.1384175441000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524772.1384175441000.25444.1391173169015@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940451#comment-12940451 ] 

Michael Musgrove commented on WFLY-2485:
----------------------------------------

Linked issue is the narayana upgrade that contains the fix
                
> @Transactional not working correctly with @Stereotype wrt. Exception handling
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2485
>                 URL: https://issues.jboss.org/browse/WFLY-2485
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Beta1
>            Reporter: David Mann
>            Assignee: Michael Musgrove
>            Priority: Minor
>
> Hi,
>  
> suppose I have a @Stereotype with a @Transactional annotation:
>  
> @Named
> @ViewScoped
> @Transactional
> @Stereotype
> @Retention (RetentionPolicy.RUNTIME)
> @Target (ElementType.TYPE)
> public @interface Boundary
> { }
>  
> I annotate a CDI Bean with this stereotype
>  
> @Boundary
> public class BusinessLogic {
>    public void doSomething(){
>         throw new RuntimeException("foo");
>    }
> }
>  
> If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
>  
> What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
>  
> java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
> Which is pretty clear from the implementation of TransactionalInterceptorBase:
>     private Transactional getTransactional(InvocationContext ic) {
>  
>         Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
>         if (transactional != null) {
>             return transactional;
>         }
>  
>         Class<?> targetClass = ic.getTarget().getClass();
>         transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
>         if (transactional != null) {
>             return transactional;
>         }
>  
>         throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
>     }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:01:31 2014
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 31 Jan 2014 08:01:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2485) @Transactional not working
 correctly with @Stereotype wrt. Exception handling
In-Reply-To: <JIRA.12524772.1384175441000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524772.1384175441000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524772.1384175441000.25449.1391173291149@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove resolved WFLY-2485.
------------------------------------

    Resolution: Done

    
> @Transactional not working correctly with @Stereotype wrt. Exception handling
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2485
>                 URL: https://issues.jboss.org/browse/WFLY-2485
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Beta1
>            Reporter: David Mann
>            Assignee: Michael Musgrove
>            Priority: Minor
>
> Hi,
>  
> suppose I have a @Stereotype with a @Transactional annotation:
>  
> @Named
> @ViewScoped
> @Transactional
> @Stereotype
> @Retention (RetentionPolicy.RUNTIME)
> @Target (ElementType.TYPE)
> public @interface Boundary
> { }
>  
> I annotate a CDI Bean with this stereotype
>  
> @Boundary
> public class BusinessLogic {
>    public void doSomething(){
>         throw new RuntimeException("foo");
>    }
> }
>  
> If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
>  
> What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
>  
> java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
> Which is pretty clear from the implementation of TransactionalInterceptorBase:
>     private Transactional getTransactional(InvocationContext ic) {
>  
>         Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
>         if (transactional != null) {
>             return transactional;
>         }
>  
>         Class<?> targetClass = ic.getTarget().getClass();
>         transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
>         if (transactional != null) {
>             return transactional;
>         }
>  
>         throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
>     }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:01:31 2014
From: issues at jboss.org (Michael Musgrove (JIRA))
Date: Fri, 31 Jan 2014 08:01:31 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2485) @Transactional not working
 correctly with @Stereotype wrt. Exception handling
In-Reply-To: <JIRA.12524772.1384175441000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12524772.1384175441000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12524772.1384175441000.25454.1391173291774@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated WFLY-2485:
-----------------------------------

    Fix Version/s: 8.0.0.Final

    
> @Transactional not working correctly with @Stereotype wrt. Exception handling
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2485
>                 URL: https://issues.jboss.org/browse/WFLY-2485
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 8.0.0.Beta1
>            Reporter: David Mann
>            Assignee: Michael Musgrove
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Hi,
>  
> suppose I have a @Stereotype with a @Transactional annotation:
>  
> @Named
> @ViewScoped
> @Transactional
> @Stereotype
> @Retention (RetentionPolicy.RUNTIME)
> @Target (ElementType.TYPE)
> public @interface Boundary
> { }
>  
> I annotate a CDI Bean with this stereotype
>  
> @Boundary
> public class BusinessLogic {
>    public void doSomething(){
>         throw new RuntimeException("foo");
>    }
> }
>  
> If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
>  
> What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
>  
> java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
>         at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
> Which is pretty clear from the implementation of TransactionalInterceptorBase:
>     private Transactional getTransactional(InvocationContext ic) {
>  
>         Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
>         if (transactional != null) {
>             return transactional;
>         }
>  
>         Class<?> targetClass = ic.getTarget().getClass();
>         transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
>         if (transactional != null) {
>             return transactional;
>         }
>  
>         throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
>     }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:17:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 31 Jan 2014 08:17:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554000.25469.1391174248756@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2841:
-------------------------------

    Workaround Description: 
Set wildfly.jpa.twophasebootstrap to false in the persistence unit definition as a workaround to have the persistence unit start as late as possible (during the INSTALL deployment phase):

<property name="wildfly.jpa.twophasebootstrap" value="false"/>
                Workaround: Workaround Exists

    
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
>                 Key: WFLY-2841
>                 URL: https://issues.jboss.org/browse/WFLY-2841
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:17:28 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 31 Jan 2014 08:17:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554000.25471.1391174248864@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2841.
--------------------------------

    Resolution: Rejected


The deployment succeeds with wildfly.jpa.twophasebootstrap set to false.
                
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
>                 Key: WFLY-2841
>                 URL: https://issues.jboss.org/browse/WFLY-2841
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:21:29 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 08:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1787) Adjust Windows command line
 parameter processing to accept more than 9 parameters.
In-Reply-To: <JIRA.12530893.1391174457758@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530893.1391174457758@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530893.1391174457758.25482.1391174489258@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1787:
-----------------------------------------

             Summary: Adjust Windows command line parameter processing to accept more than 9 parameters.
                 Key: JGRP-1787
                 URL: https://issues.jboss.org/browse/JGRP-1787
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: Windows
            Reporter: Richard Achmatowicz
            Assignee: Richard Achmatowicz
            Priority: Minor
             Fix For: 3.2.13


In the Windows build.bat script, command-line parameters are processed using the following code:

{noformat}
"%JAVA_HOME%\bin\java" -classpath "%CP%" org.apache.tools.ant.Main -buildfile build.xml %1 %2 %3 %4 %5 %6 %7 %8 %9
{noformat}

This limits the number of command-line parameters to 9, which is not sufficient for executing builds which make use of many system properties (e.g. in the QA lab).
 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:23:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 08:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1787) Adjust Windows command line
 parameter processing to accept more than 9 parameters.
In-Reply-To: <JIRA.12530893.1391174457000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530893.1391174457000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530893.1391174457000.25485.1391174608648@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940455#comment-12940455 ] 

Richard Achmatowicz commented on JGRP-1787:
-------------------------------------------

This is fixed by:

{noformat}
"%JAVA_HOME%\bin\java" -classpath "%CP%" org.apache.tools.ant.Main -buildfile build.xml %*
{noformat}

where %* represents all command-line parameters.

                
> Adjust Windows command line parameter processing to accept more than 9 parameters.
> ----------------------------------------------------------------------------------
>
>                 Key: JGRP-1787
>                 URL: https://issues.jboss.org/browse/JGRP-1787
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>            Priority: Minor
>             Fix For: 3.2.13
>
>
> In the Windows build.bat script, command-line parameters are processed using the following code:
> {noformat}
> "%JAVA_HOME%\bin\java" -classpath "%CP%" org.apache.tools.ant.Main -buildfile build.xml %1 %2 %3 %4 %5 %6 %7 %8 %9
> {noformat}
> This limits the number of command-line parameters to 9, which is not sufficient for executing builds which make use of many system properties (e.g. in the QA lab).
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:31:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 08:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1788) Backport selected testsuite
 changes from JGroups 3.4
In-Reply-To: <JIRA.12530894.1391175022461@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530894.1391175022461@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530894.1391175022461.25500.1391175088651@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1788:
-----------------------------------------

             Summary: Backport selected testsuite changes from JGroups 3.4
                 Key: JGRP-1788
                 URL: https://issues.jboss.org/browse/JGRP-1788
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 3.2.13
            Reporter: Richard Achmatowicz
            Assignee: Richard Achmatowicz
             Fix For: 3.2.13


This issue backports the following features from JGroups 3.4:
- the ability to run the testsuite in sequential mode as opposed to the default parallel mode
- the ability to better configure and run Byteman tests on different platforms

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:37:30 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 08:37:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-19) JMX over remoting pollutes
 query results with ModelController objects
In-Reply-To: <JIRA.12477448.1350636455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477448.1350636455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477448.1350636455000.25547.1391175450113@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-19:
---------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
>                 Key: WFLY-19
>                 URL: https://issues.jboss.org/browse/WFLY-19
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: NadirX
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Final
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant>      darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant>      darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant>      darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant>      darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 -->     fnasser (~fnasser at CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <--     fnasser has quit (Changing host)
> Oct 15 14:53:09 -->     fnasser (~fnasser at redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 ---     ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant>      darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl>       ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl>       For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl>       if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant>      darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl>       But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant>      darranl, wait a sec
> Oct 15 14:54:57 <darranl>       ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl>       regardless of where it is happenign it sounds like you may have discovered a bug 
> Oct 15 14:56:23 <ttarrant>      darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl>       ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration 
> Oct 15 14:56:42 <darranl>       ok
> Oct 15 15:26:08 <ttarrant>      darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl>       ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results 
> Oct 15 15:51:53 <darranl>       ttarrant: going RMI was just bypassing that as well 
> Oct 15 15:52:05 <ttarrant>      darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant>      darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl>       ttarrant:  it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back 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 issues at jboss.org  Fri Jan 31 08:37:30 2014
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 31 Jan 2014 08:37:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2841) Datasource mapped in
 jboss-web.xml not available to persistence unit
In-Reply-To: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530736.1391084554000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530736.1391084554000.25552.1391175450587@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-2841.
------------------------------


    
> Datasource mapped in jboss-web.xml not available to persistence unit
> --------------------------------------------------------------------
>
>                 Key: WFLY-2841
>                 URL: https://issues.jboss.org/browse/WFLY-2841
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Martin Andersson
>
> I have mapped the datasource java:jboss/datasources/ExampleDS to jdbc/MyDS in jboss-web.xml for my application.
> In a stateless bean i can do a jndi lookup and find the datasource in both java:comp/env/jdbc/MyDS and java:module/env/jdbc/MyDS as expected. But if I try to use it in my persistence.xml I get an error:
> 13:18:28,129 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wfds-1.0-SNAPSHOT.war#wfdsPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.\"wfds-1.0-SNAPSHOT\".\"wfds-1.0-SNAPSHOT\".env.MyDS]"]}
> A minimal example application that demonstrates the problem is available at: https://github.com/umartin/wfds/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:39:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 08:39:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2624) add-user.sh/bat should not
 automatically add users to *both* domain and standalone property files
In-Reply-To: <JIRA.12527321.1386589236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527321.1386589236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527321.1386589236000.25555.1391175568704@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2624:
-----------------------------------

    Fix Version/s: 8.0.1.Final
                       (was: Awaiting Volunteers)

    
> add-user.sh/bat should not automatically add users to *both* domain and standalone property files
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2624
>                 URL: https://issues.jboss.org/browse/WFLY-2624
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 8.0.1.Final
>
>
> The script "add-user.sh" has options to set 
>     -dc <value>      Define the location of the domain config directory.
>     -sc <value>      Define the location the server config directory.
> The class:
>   org/jboss/as/domain/management/security/state/PropertyFileFinder.java
> in
>   private boolean findFiles(final String jbossHome, final List<File> foundFiles, final String fileName) {
> will always find both files. This means that in the event the user uses only one of the above options, the new user will also be added to the default file. This is seen as a security risk.
> We propose that when only *one* of the above options is set, that the user is *not* automatically added to the other (default) file. When neither option is set, stick with the current behaviour.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:41:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 08:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.25570.1391175689079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-404:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060218

    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>         Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 31 08:41:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 08:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.25574.1391175689442@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940463#comment-12940463 ] 

RH Bugzilla Integration commented on DROOLS-404:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1060218|https://bugzilla.redhat.com/show_bug.cgi?id=1060218] from NEW to ASSIGNED
                
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mark Proctor
>         Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 31 08:41:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 08:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.25577.1391175689756@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-404:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mario Fusco
>         Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 31 08:43:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 08:43:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-761) Make the HTTP Server used for
 the HTTP interface fully manageable
In-Reply-To: <JIRA.12453439.1322651138000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12453439.1322651138000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453439.1322651138000.25588.1391175809234@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-761:
-------------------------------------

    Assignee: Darran Lofthouse

    
> Make the HTTP Server used for the HTTP interface fully manageable
> -----------------------------------------------------------------
>
>                 Key: WFLY-761
>                 URL: https://issues.jboss.org/browse/WFLY-761
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Awaiting Volunteers
>
>
> AS7-2765 makes it possible to fully configure the HTTP server instance, this task is to make it optionally configurable through the domain model with sensible defaults for anything not configured.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:43:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 08:43:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-761) Make the HTTP Server used for
 the HTTP interface fully manageable
In-Reply-To: <JIRA.12453439.1322651138000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12453439.1322651138000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453439.1322651138000.25591.1391175809448@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-761:
----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: Awaiting Volunteers)

    
> Make the HTTP Server used for the HTTP interface fully manageable
> -----------------------------------------------------------------
>
>                 Key: WFLY-761
>                 URL: https://issues.jboss.org/browse/WFLY-761
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> AS7-2765 makes it possible to fully configure the HTTP server instance, this task is to make it optionally configurable through the domain model with sensible defaults for anything not configured.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:43:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 08:43:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-484) Re visit authentication tokens
In-Reply-To: <JIRA.12465228.1335539993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465228.1335539993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465228.1335539993000.25598.1391175809929@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-484:
----------------------------------

    Fix Version/s: 9.0.0.CR1

    
> Re visit authentication tokens
> ------------------------------
>
>                 Key: WFLY-484
>                 URL: https://issues.jboss.org/browse/WFLY-484
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Common_Authentication
>             Fix For: 9.0.0.CR1
>
>
> We had previously considered authentication tokens for the realm secured interfaces, this issue is just to track re-considering them again.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 08:43:30 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 08:43:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens
 when using "function"s in drl
In-Reply-To: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529688.1389960670000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529688.1389960670000.25601.1391175810167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-404.
--------------------------------

    Fix Version/s: 6.1.0.Beta1
       Resolution: Done

    
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
>                 Key: DROOLS-404
>                 URL: https://issues.jboss.org/browse/DROOLS-404
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final, 6.0.1.Final
>         Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
>            Reporter: Nandor Galambosi
>            Assignee: Mario Fusco
>             Fix For: 6.1.0.Beta1
>
>         Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL: 
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() { 
> 	return true;
> }
> rule "rule 1" when
>     m : Message( )
> then
>     retract(m);
> end
> rule "rule 2" when
>     Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
>     insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
>     static int counter = 0;
>     public void failCase1()
>     {
>         KieServices ks = KieServices.Factory.get();
>         KieContainer kContainer = ks.getKieClasspathContainer();
>         KieSession kSession = kContainer.newKieSession();
>         for( counter = 0; counter < 10000; ++counter) {
>             kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
>             kSession.fireAllRules();
>             if (kSession.getFactCount() != 0) {
>                 System.err.println("error");
>             }
>         }
>     }
>     public static void main(String[] args)
>     {
>         try {
>             DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
>             defaultKieSessionExample.failCase1();
>         } catch (NoClassDefFoundError error) {
>             System.err.println("Failed after "+counter+" testcases");
>             error.printStackTrace();
>         }
>     }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> 	at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> 	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> 	at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> 	at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> 	... 15 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 issues at jboss.org  Fri Jan 31 08:49:28 2014
From: issues at jboss.org (Matus Abaffy (JIRA))
Date: Fri, 31 Jan 2014 08:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2847) Caller's security identity
 doesn't get propagated by default
In-Reply-To: <JIRA.12530767.1391099797000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530767.1391099797000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530767.1391099797000.25616.1391176168911@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matus Abaffy updated WFLY-2847:
-------------------------------

    Description: 
3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
{{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}

Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.

According to EJB spec, 12 Security management, 12.1 Overview:
bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
12.3.4 Specification of Security Identities in the Deployment Descriptor:
bq. "The Bean Provider or Application Assembler typically specifies whether the caller?s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller?s security identity is used."
etc.
{code}
@Stateless
@RunAs("printer")
@PermitAll
public class Printer {
    @EJB
    HelperBean hb;

    public void invokeHelperBean() {
        hb.invokeToner();
    }
}
{code}
{code}
@Stateful
public class HelperBean {
    @EJB
    Toner toner;

    public void invokeToner() {
        toner.spill();
    }
}
{code}
{code}
@Stateless
@RolesAllowed("printer")
public class Toner {
    public void spill() {}
}
{code}
A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext

  was:
3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
{{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}

Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.

According to EJB spec, 12 Security management, 12.1 Overview:
bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
12.3.4 Specification of Security Identities in the Deployment Descriptor:
bq. "The Bean Provider or Application Assembler typically specifies whether the caller?s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller?s security identity is used."
etc.
{code}
@RunAs("printer")
@PermitAll
public class Printer {
    @EJB
    HelperBean hb;

    public void invokeHelperBean() {
        hb.invokeToner();
    }
}
{code}
{code}
@Stateful
public class HelperBean {
    @EJB
    Toner toner;

    public void invokeToner() {
        toner.spill();
    }
}
{code}
{code}
@Stateless
@RolesAllowed("printer")
public class Toner {
    public void spill() {}
}
{code}
A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext


    
> Caller's security identity doesn't get propagated by default
> ------------------------------------------------------------
>
>                 Key: WFLY-2847
>                 URL: https://issues.jboss.org/browse/WFLY-2847
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: Matus Abaffy
>            Assignee: David Lloyd
>
> 3 session beans: @RunAs("printer") Printer, which calls HelperBean (no security annotations), which calls @RolesAllowed("printer") Toner. The last invocation results in
> {{javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public void org.jboss.as.test.integration.ejb.security.runas.propagation.Toner.spill() of bean: Toner is not allowed}}
> Printer calling Toner (directly) works just fine. And if the HelperBean is a CDI managed bean, it works just fine too.
> According to EJB spec, 12 Security management, 12.1 Overview:
> bq. "By default, the caller principal will be propagated as the caller identity. The Bean Provider can use the RunAs annotation to specify that a security principal that has been assigned to a specified security role be used instead. See Section 12.3.4."
> 12.3.4 Specification of Security Identities in the Deployment Descriptor:
> bq. "The Bean Provider or Application Assembler typically specifies whether the caller?s security identity should be used for the execution of the methods of an enterprise bean or whether a specific run-as identity should be used. By default the caller?s security identity is used."
> etc.
> {code}
> @Stateless
> @RunAs("printer")
> @PermitAll
> public class Printer {
>     @EJB
>     HelperBean hb;
>     public void invokeHelperBean() {
>         hb.invokeToner();
>     }
> }
> {code}
> {code}
> @Stateful
> public class HelperBean {
>     @EJB
>     Toner toner;
>     public void invokeToner() {
>         toner.spill();
>     }
> }
> {code}
> {code}
> @Stateless
> @RolesAllowed("printer")
> public class Toner {
>     public void spill() {}
> }
> {code}
> A bit sophisticated test available at: https://github.com/bafco/wildfly/commits/securityContext

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 08:49:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 08:49:29 -0500 (EST)
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.25620.1391176169208@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:
-----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


Peter - is this one that should come your way?
                
> Vault.sh logging improvements
> -----------------------------
>
>                 Key: WFLY-2100
>                 URL: https://issues.jboss.org/browse/WFLY-2100
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chris Dolphy
>            Assignee: Peter Skopek
>             Fix For: 9.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 issues at jboss.org  Fri Jan 31 09:03:29 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 31 Jan 2014 09:03:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2611) Unify JSF action listener and
 CDI integration
In-Reply-To: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527051.1386241760000.25674.1391177009457@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated WFLY-2611:
------------------------------

              Summary: Unify JSF action listener and CDI integration  (was: Support CDI injection in various JSF artifacts)
             Assignee: Farah Juma  (was: Stuart Douglas)
    Affects Version/s: 8.0.0.CR1
          Description: 
There are three ways, how can user specify custom JSF action listener:

1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.

2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class. 

3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed. 

Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listeners-injection. Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
 

  was:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec). 
So far I tried locally this (will be filling the table during time):

||JSF artifact||CDI Injection||
|javax.el.ELResolver|works|
|javax.faces.application.ApplicationFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.application.NavigationHandler|works|
|javax.faces.application.ResourceHandler|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
|javax.faces.component.visit.VisitContextFactory|works|
|javax.faces.context.ExceptionHandlerFactory|works|
|javax.faces.context.ExternalContextFactory|works|
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.FlashFactory|works|
|javax.faces.context.PartialViewContextFactory|works|
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.lifecycle.ClientWindowFactory|works|
|javax.faces.lifecycle.LifecycleFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.view.ViewDeclarationLanguageFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.view.facelets.FaceletCacheFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
|javax.faces.view.facelets.TagHandlerDelegateFactory|works|
 


    
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
>                 Key: WFLY-2611
>                 URL: https://issues.jboss.org/browse/WFLY-2611
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class. 
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed. 
> Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listeners-injection. Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 09:03:32 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 31 Jan 2014 09:03:32 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2611) Unify JSF action listener and
 CDI integration
In-Reply-To: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527051.1386241760000.25747.1391177012877@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933777#comment-12933777 ] 

Tomas Remes edited comment on WFLY-2611 at 1/31/14 9:02 AM:
------------------------------------------------------------

I've realized that the original issue was too general (and basically all functionality works as expected IMO), so I've changed the description to be more specific. 
                
      was (Author: tremes):
    In JSF spec there is also following sentence: "..the following JSF artifacts are also injectable."  followed by the classes listed above. I am not sure, if I understand it correctly. Does it mean that when I create e.g my custom NavigationHandler (and specify it in faces-config), should it be available for injection? e.g like this:

{noformat}
@Inject
CustomNavigationHandler handler;
{noformat}

[~ssilvert] Can you please elaborate? 
                  
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
>                 Key: WFLY-2611
>                 URL: https://issues.jboss.org/browse/WFLY-2611
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class. 
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed. 
> Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listeners-injection. Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 09:05:29 2014
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Fri, 31 Jan 2014 09:05:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2611) Unify JSF action listener and
 CDI integration
In-Reply-To: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527051.1386241760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527051.1386241760000.25751.1391177129004@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Remes updated WFLY-2611:
------------------------------

    Description: 
There are three ways, how can user specify custom JSF action listener:

1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.

2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class. 

3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed. 

Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listeners-injection. Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
 

  was:
There are three ways, how can user specify custom JSF action listener:

1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.

2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class. 

3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed. 

Producer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listeners-injection. Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
 


    
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
>                 Key: WFLY-2611
>                 URL: https://issues.jboss.org/browse/WFLY-2611
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.CR1
>            Reporter: Tomas Remes
>            Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class. 
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed. 
> Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listeners-injection. Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 09:21:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 31 Jan 2014 09:21:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1901) Could not grant
 javax.xml.ws.WebServicePermission to a deployment
In-Reply-To: <JIRA.12498910.1376929649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498910.1376929649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498910.1376929649000.25787.1391178089845@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940478#comment-12940478 ] 

Stuart Douglas commented on WFLY-1901:
--------------------------------------

In my PR I have added a module attribute that allows you to specify the module to load the permission from.
                
> Could not grant javax.xml.ws.WebServicePermission to a deployment
> -----------------------------------------------------------------
>
>                 Key: WFLY-1901
>                 URL: https://issues.jboss.org/browse/WFLY-1901
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security Manager
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alessio Soldano
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.Final
>
>
> It's currently not possible by default to grant the javax.xml.ws.WebServicePermission "publish" permission to a user deployment by adding the proper entry in standalone.xml:
> {noformat}
>         <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
>             <deployment-permissions>
>                 <minimum-set>
>                     ...
>                     <permission class="javax.xml.ws.WebServicePermission" name="publishEndpoint"/>
>                 </minimum-set>
>             </deployment-permissions>
>         </subsystem>
> {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 issues at jboss.org  Fri Jan 31 09:23:28 2014
From: issues at jboss.org (Harald Wellmann (JIRA))
Date: Fri, 31 Jan 2014 09:23:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2851) Can't validate
 jboss-deployment-structure.xml due to incorrect schema
In-Reply-To: <JIRA.12530900.1391178113550@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530900.1391178113550@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530900.1391178113550.25793.1391178208604@jira02.app.mwc.hst.phx2.redhat.com>

Harald Wellmann created WFLY-2851:
-------------------------------------

             Summary: Can't validate jboss-deployment-structure.xml due to incorrect schema
                 Key: WFLY-2851
                 URL: https://issues.jboss.org/browse/WFLY-2851
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.CR1
            Reporter: Harald Wellmann


The following deployment structure cannot be validated against the XML schema:

{code:xml}
<jboss-deployment-structure  xmlns="urn:jboss:deployment-structure:1.2">

    <deployment>
        <dependencies>
            <module name="foo"/>
        </dependencies>
    </deployment>

</jboss-deployment-structure>
{code}

This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="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 issues at jboss.org  Fri Jan 31 09:41:30 2014
From: issues at jboss.org (Harald Wellmann (JIRA))
Date: Fri, 31 Jan 2014 09:41:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2851) Can't validate
 jboss-deployment-structure.xml due to incorrect schema
In-Reply-To: <JIRA.12530900.1391178113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530900.1391178113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530900.1391178113000.25860.1391179290438@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Wellmann updated WFLY-2851:
----------------------------------

    Description: 
The following deployment structure cannot be validated against the XML schema:

{code:xml}
<jboss-deployment-structure  xmlns="urn:jboss:deployment-structure:1.2">

    <deployment>
        <dependencies>
            <module name="foo"/>
        </dependencies>
    </deployment>

</jboss-deployment-structure>
{code}

This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.

The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.

  was:
The following deployment structure cannot be validated against the XML schema:

{code:xml}
<jboss-deployment-structure  xmlns="urn:jboss:deployment-structure:1.2">

    <deployment>
        <dependencies>
            <module name="foo"/>
        </dependencies>
    </deployment>

</jboss-deployment-structure>
{code}

This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.


    
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2851
>                 URL: https://issues.jboss.org/browse/WFLY-2851
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Harald Wellmann
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure  xmlns="urn:jboss:deployment-structure:1.2">
>     <deployment>
>         <dependencies>
>             <module name="foo"/>
>         </dependencies>
>     </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 10:15:34 2014
From: issues at jboss.org (Chris Dolphy (JIRA))
Date: Fri, 31 Jan 2014 10:15:34 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-373) [backport JBMETA-371]
 DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530507.1390925363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530507.1390925363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530507.1390925363000.25930.1391181334449@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940500#comment-12940500 ] 

Chris Dolphy commented on JBMETA-373:
-------------------------------------

Pull request to add JBMETA-371 to 7.0.9
https://github.com/jboss/metadata/pull/58
                
> [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-373
>                 URL: https://issues.jboss.org/browse/JBMETA-373
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4.Final
>            Reporter: Chris Dolphy
>            Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 31 10:39:29 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 31 Jan 2014 10:39:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2522) Error when invoking @Remove
 method for stateful bean in transaction
In-Reply-To: <JIRA.12525373.1384610529000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525373.1384610529000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525373.1384610529000.25950.1391182769271@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2522:
---------------------------------

              Priority: Major  (was: Blocker)
    Steps to Reproduce: 
1- Download projects from http://www.filedropper.com/jbosstxsyncerror

The zip contains 3 projects

JBossTxSyncError : EJB Project

JBossTxSyncErrorClient : EJB Client Project

JBossTxSyncErrorEar : Ear project

2- Import project into Eclipse

3- add required libraries in build path

JBossTxSyncError

JBoss 7.1 Runtime

JBossTxSyncErrorClient

jboss-client.jar

jboss-ejb-api_3.1_spec-1.0.2.Final.jar

4- create table using create.sql file under JBossTxSyncErrorClient

5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient

6- configure a datasource for mysql connection

7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi

8- deploy ear file and run OldEjbClient.java

  was:

1- Download projects from http://www.filedropper.com/jbosstxsyncerror

The zip contains 3 projects

JBossTxSyncError : EJB Project

JBossTxSyncErrorClient : EJB Client Project

JBossTxSyncErrorEar : Ear project

2- Import project into Eclipse

3- add required libraries in build path

JBossTxSyncError

JBoss 7.1 Runtime

JBossTxSyncErrorClient

jboss-client.jar

jboss-ejb-api_3.1_spec-1.0.2.Final.jar

4- create table using create.sql file under JBossTxSyncErrorClient

5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient

6- configure a datasource for mysql connection

7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi

8- deploy ear file and run OldEjbClient.java



This only occurs if you attempt to remove an EJB in a transaction synchronization callback. 
                
> Error when invoking @Remove method for stateful bean in transaction
> -------------------------------------------------------------------
>
>                 Key: WFLY-2522
>                 URL: https://issues.jboss.org/browse/WFLY-2522
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: noel a.a
>            Assignee: David Lloyd
>
> I'm invoking method annotated with @Remove
> {code}
> @Remove
> public void remove() {
> ...
> {code}
> On invocation inside active transaction I'm getting following error :
> {noformat}
> Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:374)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:351)
> at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:165) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:57) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:283) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> 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.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> 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:200) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> ... 140 more
> {noformat}
> EJB Spec paragraphe 4.6.4 states:
> {quote}
> If a session bean instance is participating in a transaction, it is an error for a client to invoke the remove method on the session object?s home or component interface object. The container must detect such an attempt and throw the javax.ejb.RemoveException to the client. The container should not mark the client?s transaction for rollback, thus allowing the client to recover. Note that this restriction only applies to the remove method on the session object?s home or component interface, not to the invocation of @Remove methods.
> {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 issues at jboss.org  Fri Jan 31 10:45:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 31 Jan 2014 10:45:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer +
 PropertyResolver is broken for vault expressions
In-Reply-To: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530165.1390432775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530165.1390432775000.25975.1391183130117@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBMETA-371:
-------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1056799, https://bugzilla.redhat.com/show_bug.cgi?id=1058959, https://bugzilla.redhat.com/show_bug.cgi?id=1060260  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1056799, https://bugzilla.redhat.com/show_bug.cgi?id=1058959)

    
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
>                 Key: JBMETA-371
>                 URL: https://issues.jboss.org/browse/JBMETA-371
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: common
>    Affects Versions: 7.0.4.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Final
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default 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 issues at jboss.org  Fri Jan 31 10:47:28 2014
From: issues at jboss.org (Aleksandar Kostadinov (JIRA))
Date: Fri, 31 Jan 2014 10:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2785) master reload on windows
 using bind IP without a reverse DNS entry (or a wrong one)
In-Reply-To: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530043.1390337395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530043.1390337395000.25981.1391183248827@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandar Kostadinov closed WFLY-2785.
---------------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2785
>                 URL: https://issues.jboss.org/browse/WFLY-2785
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.CR1
>         Environment: windows
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: addressing, domain, socket
>             Fix For: 8.0.0.Final
>
>         Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>  
>  import java.io.IOException;
>  import java.io.OutputStream;
> -import java.net.InetAddress;
>  import java.net.InetSocketAddress;
>  import java.util.Collections;
>  import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
>          public boolean execute(ManagedServer server) throws Exception {
>              assert Thread.holdsLock(ManagedServer.this); // Call under lock
>              // Reconnect
> -            final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> +            final String hostName = managementSocket.getHostString();
>              final int port = managementSocket.getPort();
>              processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
>              return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a059167bc2c41664c29117] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 11:01:30 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 11:01:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-383) switch over String in
	function
In-Reply-To: <JIRA.12528208.1387448314000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528208.1387448314000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528208.1387448314000.26017.1391184090326@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940514#comment-12940514 ] 

Mario Fusco commented on DROOLS-383:
------------------------------------

The problem is not only in functions. It happens exactly the same if you try to use the switch over String directly in a consequence.
That error message is generated by the Eclipse Java Compiler the we are using internally at the moment.
The only way to fix this is to migrate to the native Java compiler that it is something that we have already planned.
This is only a reason more to make this migration asap. 
                
> switch over String in function
> ------------------------------
>
>                 Key: DROOLS-383
>                 URL: https://issues.jboss.org/browse/DROOLS-383
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Matteo Mortari
>            Assignee: Mark Proctor
>         Attachments: 20131219.drools6scratch-switchoverstring.zip
>
>
> *Executive Summary*: if I try to implement switch over String as per Java 1.7, inside of DRL function, compilation of DRL fails, but the error message would suggest that actually switch over String should work.
> *Steps to reproduce*
> Have a DRL file with function with String parameter and inside the function a switch over the parameter, for example
> {code:title=acme.drl|borderStyle=solid}
> rule "Stupid rule over String"
> when
> 	String()
> then
> 	System.out.println("Hello world");
> end
> function void theTest(String input) {
> 	switch(input) {
> 		case "Hello World" : 
> 			System.out.println("yep");
> 			break;
> 		default :
> 			System.out.println("uh");
> 			break;
> 	}
> }
> {code}
> Have simple code to compile DRL for default KieBase, for example snippet:
> {code:title=App.java|borderStyle=solid}
> String input = "Hello World";
> // Java 1.7
> switch(input) {
> 	case "Hello World" : 
> 		System.out.println("yep");
> 		break;
> 	default :
> 		System.out.println("uh");
> 		break;
> }
> System.out.println( "Hello World!" );
> KieServices ks = KieServices.Factory.get();
> KieContainer kContainer = ks.getKieClasspathContainer();
> KieBase kieBase = kContainer.getKieBase();
> for ( KiePackage kp : kieBase.getKiePackages() ) {
> 	for (Rule rule : kp.getRules()) {
> 		System.out.println("kp" + kp + " rule " + rule.getName());
> 	}
> }
> {code}
> Console would log DRL compile fails with error:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=acme.drl, line=-1, column=0
>    text=Error importing : 'defaultpkg.TheTest.theTest'], Message [id=2, level=ERROR, path=acme.drl, line=8, column=0
>    text=[ function theTesttheTest (line:8): Cannot switch on a value of type String. Only convertible int values, strings or enum constants are permitted
>  ]], Message [id=3, level=ERROR, path=acme.drl, line=1, column=0
>    text=Rule Compilation error The import defaultpkg.TheTest cannot be resolved]]
> {noformat}
> Please notice the 'strings' bit in the error message : {{Cannot switch on a value of type String. Only convertible int values, *strings* or enum constants are permitted}}
> Therefore would suggest it would compile a switch over String, but for some reason it is failing to recognize that input parameter is indeed a String?
> Thank you
> Ciao
> MM

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 11:07:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 31 Jan 2014 11:07:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2838) Revisit default mod_cluster
 metric for WildFly 8
In-Reply-To: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530685.1391028993000.26020.1391184448629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940515#comment-12940515 ] 

Radoslav Husar commented on WFLY-2838:
--------------------------------------

Stuart is fine with CPU.
                
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
>                 Key: WFLY-2838
>                 URL: https://issues.jboss.org/browse/WFLY-2838
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity.. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 11:23:29 2014
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 31 Jan 2014 11:23:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with
 kieServices.newKieContainer() with LATEST or RELEASE instead of explicit
 version number (eg: 0.0.1) on a application where the KIE module Rule
 artifact project kjar has been locally-installed from remote Maven
 repository.
In-Reply-To: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530799.1391109809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530799.1391109809000.26055.1391185409292@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-419:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-419
>                 URL: https://issues.jboss.org/browse/DROOLS-419
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.1.Final
>         Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: 20140130.drools6testmvnlatest.zip
>
>
> Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
> More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , I mean that before launching Application, I performed 
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> h5. Disclaimer
> I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.
> h5. DETAILS
> Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .
> Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
> {code:title=App.java}
> public static void main( String[] args ) {
> 	KieServices kieServices = KieServices.Factory.get();
> 	ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
> 	KieContainer kContainer = kieServices.newKieContainer( releaseId );
> 	KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
> 	kieBaseConf.setOption( EventProcessingOption.STREAM );
> 	KieBase kBase = kContainer.newKieBase(kieBaseConf);
> 	for ( KiePackage a : kBase.getKiePackages()) {
> 			for (Rule r : a.getRules()) {
> 				logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
> 			}
> 	}
> }
> {code}
> The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
> {code}
> Execution of
> {code}
> java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
> {code}
> Would generate the following stack trace
> {code}
> Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
>         at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
>         at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
> {code}
> Same for LATEST as launch parameter.
> But fixed version, eg: 0.0.2 as launch parameter, will work.
> {code}
> D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
> 2014-01-30 19:24:12,128 [main] INFO  org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
> 2014-01-30 19:24:12,440 [main] INFO  com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
> {code}
> Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h5. WORKAROUND
> The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
> h6. Workaround Option 1
> Do 'fake' a pom.xml with the dependency, something similar to:
> {code}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>   <modelVersion>4.0.0</modelVersion>
>   <groupId>com.acme</groupId>
>   <artifactId>fakepom</artifactId>
>   <version>0.0.1</version>
>   <packaging>jar</packaging>
>   <dependencies>
>     <dependency>
>       <groupId>com.acme</groupId>
>       <artifactId>drools6testmvnlatest.therules</artifactId>
>       <version>RELEASE</version>
>     </dependency>
>   </dependencies>
>   
> </project>
> {code}
> And then launch maven in the same directory of this 'fake' pom.xml with the following command:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline 
> {code}
> This usually generate the 'maven-metadata-local' file in the local .m2 repo:
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-nexus-hostname-nexus.xml
>     ?   maven-metadata-nexus-hostname-nexus.xml.sha1
>     ?   maven-metadata-local.xml
>     ?   maven-metadata-local.xml.sha1
>     ?   maven-metadata-temp.xml
>     ?   maven-metadata-temp.xml.sha1
>     ?   resolver-status.properties
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.jar.sha1
>             drools6testmvnlatest.therules-0.0.2.pom
>             drools6testmvnlatest.therules-0.0.2.pom.sha1
>             _remote.repositories
> {code}
> h6. Workaround Option2
> Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.
> h6. Workaround Option3
> Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven 
> {code}
> D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
> {code}
> This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
> {code}
> D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
> ????drools6testmvnlatest.therules
>     ?   maven-metadata-local.xml
>     ?
>     ????0.0.2
>             drools6testmvnlatest.therules-0.0.2.jar
>             drools6testmvnlatest.therules-0.0.2.pom
>             _remote.repositories
> {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 issues at jboss.org  Fri Jan 31 11:23:29 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 31 Jan 2014 11:23:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2838) Revisit default mod_cluster
 metric for WildFly 8
In-Reply-To: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530685.1391028993000.26058.1391185409660@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940525#comment-12940525 ] 

Radoslav Husar commented on WFLY-2838:
--------------------------------------

JFC would prefer autogenerating capacity of the busyness metric (e.g. in JBW it is 128 requests per sec per CPU) [or session.]
                
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
>                 Key: WFLY-2838
>                 URL: https://issues.jboss.org/browse/WFLY-2838
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity.. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 11:27:28 2014
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 31 Jan 2014 11:27:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2851) Can't validate
 jboss-deployment-structure.xml due to incorrect schema
In-Reply-To: <JIRA.12530900.1391178113000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530900.1391178113000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530900.1391178113000.26075.1391185648793@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2851:
------------------------------------

    Assignee: Stuart Douglas

    
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2851
>                 URL: https://issues.jboss.org/browse/WFLY-2851
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.CR1
>            Reporter: Harald Wellmann
>            Assignee: Stuart Douglas
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure  xmlns="urn:jboss:deployment-structure:1.2">
>     <deployment>
>         <dependencies>
>             <module name="foo"/>
>         </dependencies>
>     </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 11:55:28 2014
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 31 Jan 2014 11:55:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2838) Revisit default mod_cluster
 metric for WildFly 8
In-Reply-To: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530685.1391028993000.26137.1391187328659@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940544#comment-12940544 ] 

Radoslav Husar commented on WFLY-2838:
--------------------------------------

The "default" thread pool is server-wide -- so any subsystem can use those threads. Which might be an interesting metric, but might not be an ideal default.
                
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
>                 Key: WFLY-2838
>                 URL: https://issues.jboss.org/browse/WFLY-2838
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity.. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 11:59:28 2014
From: issues at jboss.org (nathan dennis (JIRA))
Date: Fri, 31 Jan 2014 11:59:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1376)
 HttpServletResponseImpl.getWriter() cannot be called: getOutputStream()
 already called
In-Reply-To: <JIRA.12492418.1369219332000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492418.1369219332000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492418.1369219332000.26140.1391187568709@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940545#comment-12940545 ] 

nathan dennis commented on WFLY-1376:
-------------------------------------

I am also seeing this on CR1
                
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-1376
>                 URL: https://issues.jboss.org/browse/WFLY-1376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
>   <error-page>
>     <error-code>404</error-code>
>     <location>/error/pageNotFound.jsf</location>
>   </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	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 issues at jboss.org  Fri Jan 31 12:25:28 2014
From: issues at jboss.org (Sfe Br (JIRA))
Date: Fri, 31 Jan 2014 12:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2852) JBoss 7 - EJB Remote
	Transaction Timeout
In-Reply-To: <JIRA.12530939.1391189103141@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530939.1391189103141@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530939.1391189103141.26186.1391189128496@jira02.app.mwc.hst.phx2.redhat.com>

Sfe Br created WFLY-2852:
----------------------------

             Summary: JBoss 7 - EJB Remote Transaction Timeout
                 Key: WFLY-2852
                 URL: https://issues.jboss.org/browse/WFLY-2852
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Sfe Br
             Fix For: JBoss AS7 7.2.0.Final


I have a remote call that allow to run a process that takes more than 5 minutes, after passing this time the transaction was canceled and the global transaction was rollbacked at the commit phase.

The problem is that i can't modify the timeout value.

Note: After consulting the method createOrResumeXidTransaction of the EJBRemoteTransactionPropagatingInterceptor class, I found that the timeout value is always 300 seconds (it seems that this value is hardcoded)

You can refer to my discussion with jaikiran pai: https://community.jboss.org/thread/236493

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 issues at jboss.org  Fri Jan 31 13:55:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 31 Jan 2014 13:55:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1376)
 HttpServletResponseImpl.getWriter() cannot be called: getOutputStream()
 already called
In-Reply-To: <JIRA.12492418.1369219332000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492418.1369219332000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492418.1369219332000.26368.1391194529932@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940582#comment-12940582 ] 

Tomaz Cerar commented on WFLY-1376:
-----------------------------------

can you try with latest nightly build https://community.jboss.org/thread/224262
                
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-1376
>                 URL: https://issues.jboss.org/browse/WFLY-1376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
>   <error-page>
>     <error-code>404</error-code>
>     <location>/error/pageNotFound.jsf</location>
>   </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> 	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 issues at jboss.org  Fri Jan 31 14:05:28 2014
From: issues at jboss.org (Andre Dietisheim (JIRA))
Date: Fri, 31 Jan 2014 14:05:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2635) HTTP Management Interface
	Configuration
In-Reply-To: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527655.1386765053000.26382.1391195128908@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940583#comment-12940583 ] 

Andre Dietisheim commented on WFLY-2635:
----------------------------------------

I'll have a go for this one and try to provide the changes to allow the ip- and useragent- based filters to be configured for the management server. I currently have the filters enabled but missing the configuration part.
                
> HTTP Management Interface Configuration
> ---------------------------------------
>
>                 Key: WFLY-2635
>                 URL: https://issues.jboss.org/browse/WFLY-2635
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine 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 issues at jboss.org  Fri Jan 31 14:07:28 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 14:07:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2635) HTTP Management Interface
	Configuration
In-Reply-To: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527655.1386765053000.26389.1391195248544@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940584#comment-12940584 ] 

Darran Lofthouse commented on WFLY-2635:
----------------------------------------

This is actually going to be a much bigger task than just that one config item, we have quite a lot of additional items to get into the configuration.
                
> HTTP Management Interface Configuration
> ---------------------------------------
>
>                 Key: WFLY-2635
>                 URL: https://issues.jboss.org/browse/WFLY-2635
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine 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 issues at jboss.org  Fri Jan 31 14:49:29 2014
From: issues at jboss.org (Joshua Wilson (JIRA))
Date: Fri, 31 Jan 2014 14:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-943) XML schema;
 use of elementFormDefault='unqualified'; cannot validate some documents
In-Reply-To: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473954.1346995775000.26543.1391197769741@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940596#comment-12940596 ] 

Joshua Wilson commented on WFLY-943:
------------------------------------

Looks like this was fixed on Wildfly. 

https://github.com/wildfly/wildfly/pull/5560
                
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-943
>                 URL: https://issues.jboss.org/browse/WFLY-943
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Elias Ross
>             Fix For: 8.0.0.Final
>
>         Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd:            elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd:  elementFormDefault="unqualified" 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 15:15:29 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 31 Jan 2014 15:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2853) JSFFailoverTestCase fails
 since latest clustring / session changes in UT
In-Reply-To: <JIRA.12530960.1391199250226@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530960.1391199250226@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530960.1391199250226.26606.1391199329442@jira02.app.mwc.hst.phx2.redhat.com>

Tomaz Cerar created WFLY-2853:
---------------------------------

             Summary: JSFFailoverTestCase fails since latest clustring / session changes in UT
                 Key: WFLY-2853
                 URL: https://issues.jboss.org/browse/WFLY-2853
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.CR1
            Reporter: Tomaz Cerar
            Assignee: Paul Ferraro
            Priority: Blocker
             Fix For: 8.0.0.Final


Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164
JSFFailoverTestCase is failing.

I have ignored it for time being 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 15:17:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 31 Jan 2014 15:17:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2853) JSFFailoverTestCase fails
 since latest clustring / session changes in UT
In-Reply-To: <JIRA.12530960.1391199250000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530960.1391199250000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530960.1391199250000.26612.1391199448790@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2853:
------------------------------

    Description: 
Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164
JSFFailoverTestCase is failing.

example of failure: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=9076&buildTypeId=WFPR

{noformat}
org.junit.ComparisonFailure: expected:<...COz6P7qxwwkkxE.node-[0]> but was:<...COz6P7qxwwkkxE.node-[1]>
    at org.junit.Assert.assertEquals(Assert.java:115)
    at org.junit.Assert.assertEquals(Assert.java:144)
    at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:268)
{noformat}

  was:
Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164
JSFFailoverTestCase is failing.

I have ignored it for time being 


    
> JSFFailoverTestCase fails since latest clustring / session changes in UT
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2853
>                 URL: https://issues.jboss.org/browse/WFLY-2853
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Tomaz Cerar
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Since upgrade to Undertow CR2 which contains https://github.com/undertow-io/undertow/pull/164
> JSFFailoverTestCase is failing.
> example of failure: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=9076&buildTypeId=WFPR
> {noformat}
> org.junit.ComparisonFailure: expected:<...COz6P7qxwwkkxE.node-[0]> but was:<...COz6P7qxwwkkxE.node-[1]>
>     at org.junit.Assert.assertEquals(Assert.java:115)
>     at org.junit.Assert.assertEquals(Assert.java:144)
>     at org.jboss.as.test.clustering.cluster.jsf.JSFFailoverTestCase.testGracefulSimpleFailover(JSFFailoverTestCase.java:268)
> {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 issues at jboss.org  Fri Jan 31 15:33:28 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Fri, 31 Jan 2014 15:33:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2698) Transaction Aware EE
 Concurrency EJB Context Handle
In-Reply-To: <JIRA.12528494.1388499855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528494.1388499855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528494.1388499855000.26628.1391200408687@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940604#comment-12940604 ] 

Eduardo Martins commented on WFLY-2698:
---------------------------------------

the allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236
                
> Transaction Aware EE Concurrency EJB Context Handle
> ---------------------------------------------------
>
>                 Key: WFLY-2698
>                 URL: https://issues.jboss.org/browse/WFLY-2698
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> When using EE Concurrency Utilities with an EJB that does not manages transactions, there is no way to transactions, for instance with a JPA entity manager. This happens because the context handle that saves and sets up EJB state does not creates and manages a transaction, and UserTransaction usage is forbidden due to EJB being of CMT kind.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 15:33:28 2014
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Fri, 31 Jan 2014 15:33:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2698) Transaction Aware EE
 Concurrency EJB Context Handle
In-Reply-To: <JIRA.12528494.1388499855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528494.1388499855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528494.1388499855000.26629.1391200408782@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940604#comment-12940604 ] 

Eduardo Martins edited comment on WFLY-2698 at 1/31/14 3:32 PM:
----------------------------------------------------------------

the new PR allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236
                
      was (Author: emmartins):
    the allows tasks created by CMT EJB to access UserTransaction, as mandated by JSR 236
                  
> Transaction Aware EE Concurrency EJB Context Handle
> ---------------------------------------------------
>
>                 Key: WFLY-2698
>                 URL: https://issues.jboss.org/browse/WFLY-2698
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> When using EE Concurrency Utilities with an EJB that does not manages transactions, there is no way to transactions, for instance with a JPA entity manager. This happens because the context handle that saves and sets up EJB state does not creates and manages a transaction, and UserTransaction usage is forbidden due to EJB being of CMT kind.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 16:01:30 2014
From: issues at jboss.org (Andre Dietisheim (JIRA))
Date: Fri, 31 Jan 2014 16:01:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2635) HTTP Management Interface
	Configuration
In-Reply-To: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527655.1386765053000.26691.1391202090937@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940609#comment-12940609 ] 

Andre Dietisheim commented on WFLY-2635:
----------------------------------------

I^d be glad to contribute at least the parts that are related to the management-filters. Should we create sub-tasks?
                
> HTTP Management Interface Configuration
> ---------------------------------------
>
>                 Key: WFLY-2635
>                 URL: https://issues.jboss.org/browse/WFLY-2635
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine 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 issues at jboss.org  Fri Jan 31 16:07:30 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 31 Jan 2014 16:07:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2723) Accessing "serverInventory"
 without holding lock "serverInventoryLock"
In-Reply-To: <JIRA.12528821.1389176731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12528821.1389176731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528821.1389176731000.26741.1391202450247@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2723.
---------------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> Accessing "serverInventory" without holding lock "serverInventoryLock"
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2723
>                 URL: https://issues.jboss.org/browse/WFLY-2723
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Rostislav Svoboda
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> Accessing "serverInventory" without holding lock "org.jboss.as.host.controller.DomainModelControllerService.serverInventoryLock". 
> Elsewhere, "serverInventory" is accessed with "DomainModelControllerService.serverInventoryLock" held 4 out of 5 times.
> https://github.com/wildfly/wildfly/blob/master/host-controller/src/main/java/org/jboss/as/host/controller/DomainModelControllerService.java#L364

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 16:07:30 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 31 Jan 2014 16:07:30 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2791) Remove jboss-marshalling mvn
 dependency from the management protocol
In-Reply-To: <JIRA.12530116.1390406595000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530116.1390406595000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530116.1390406595000.26747.1391202450942@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2791.
---------------------------------------

    Resolution: Done

    
> Remove jboss-marshalling mvn dependency from the management protocol
> --------------------------------------------------------------------
>
>                 Key: WFLY-2791
>                 URL: https://issues.jboss.org/browse/WFLY-2791
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> The wildfly-protocol depends on jboss-marshalling although it should not be used for a while now. We need to verify that it's not used any more and remove 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 issues at jboss.org  Fri Jan 31 16:09:28 2014
From: issues at jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 31 Jan 2014 16:09:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2558) Patching core Test failure
In-Reply-To: <JIRA.12525989.1385304683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12525989.1385304683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12525989.1385304683000.26754.1391202568764@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2558.
---------------------------------------

    Fix Version/s: 8.0.0.Final
       Resolution: Done

    
> Patching core Test failure
> --------------------------
>
>                 Key: WFLY-2558
>                 URL: https://issues.jboss.org/browse/WFLY-2558
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>         Environment: JDK 8-ea-b115, Linux Ubuntu 64-bit
>            Reporter: Yosi Pramajaya
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Final
>
>
> Running org.jboss.as.patching.tests.PatchModuleInvalidationTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.135 sec <<< FAILURE! - in org.jboss.as.patching.tests.PatchModuleInvalidationTestCase
> test(org.jboss.as.patching.tests.PatchModuleInvalidationTestCase)  Time elapsed: 0.13 sec  <<< FAILURE!
> java.lang.AssertionError: null
> 	at org.junit.Assert.fail(Assert.java:86)
> 	at org.junit.Assert.assertTrue(Assert.java:41)
> 	at org.junit.Assert.assertNotNull(Assert.java:621)
> 	at org.junit.Assert.assertNotNull(Assert.java:631)
> 	at org.jboss.as.patching.tests.PatchModuleInvalidationTestCase.assertLoadable(PatchModuleInvalidationTestCase.java:192)
> 	at org.jboss.as.patching.tests.PatchModuleInvalidationTestCase.test(PatchModuleInvalidationTestCase.java:77)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 16:13:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 16:13:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1789) Fix host binding of tests
 involving GossipRouter
In-Reply-To: <JIRA.12530964.1391202692625@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530964.1391202692625@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530964.1391202692625.26796.1391202808837@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1789:
-----------------------------------------

             Summary: Fix host binding of tests involving GossipRouter
                 Key: JGRP-1789
                 URL: https://issues.jboss.org/browse/JGRP-1789
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.13
         Environment: Windows
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.2.13


Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter.

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of 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 issues at jboss.org  Fri Jan 31 16:15:29 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 16:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1789) Fix host binding of tests
 involving GossipRouter
In-Reply-To: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530964.1391202692000.26816.1391202929214@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940618#comment-12940618 ] 

Richard Achmatowicz commented on JGRP-1789:
-------------------------------------------

Both of these tests create their own stack involving TUNNEL and this stack does not explicitly set the bind address passed into the test case. 
Both the GossipRouter and the TUNNEL protocol should probably use the same jgroups.bind_addr to avoid this sort of failure.

                
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
>                 Key: JGRP-1789
>                 URL: https://issues.jboss.org/browse/JGRP-1789
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter.
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of 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 issues at jboss.org  Fri Jan 31 16:15:29 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 16:15:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1789) Fix host binding of tests
 involving GossipRouter
In-Reply-To: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530964.1391202692000.26818.1391202929392@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1789:
--------------------------------------

    Description: 
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
 

  was:
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter.

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
 


    
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
>                 Key: JGRP-1789
>                 URL: https://issues.jboss.org/browse/JGRP-1789
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of 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 issues at jboss.org  Fri Jan 31 16:21:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 31 Jan 2014 16:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-11) Bundle path for Embedded server
 still not working properly
In-Reply-To: <JIRA.12484275.1360227252000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484275.1360227252000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484275.1360227252000.26830.1391203288631@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-11:
----------------------------------

       Fix Version/s:     (was: 8.0.0.CR1)
    Git Pull Request: https://github.com/wildfly/wildfly/pull/5830

    
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
>                 Key: WFLY-11
>                 URL: https://issues.jboss.org/browse/WFLY-11
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarre?o
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> Error is:
> {code}  io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 16:21:28 2014
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 31 Jan 2014 16:21:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-11) Bundle path for Embedded server
 still not working properly
In-Reply-To: <JIRA.12484275.1360227252000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484275.1360227252000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484275.1360227252000.26832.1391203288848@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-11.
-----------------------------------

    Resolution: Done


Fixed.
                
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
>                 Key: WFLY-11
>                 URL: https://issues.jboss.org/browse/WFLY-11
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarre?o
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> Error is:
> {code}  io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 16:23:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 16:23:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2809) JACC
 PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
In-Reply-To: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530308.1390580046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530308.1390580046000.26840.1391203409105@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene resolved WFLY-2809.
--------------------------------

    Resolution: Done

    
> JACC PolicyContext.getContext("javax.servlet.http.HttpServletRequest")
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2809
>                 URL: https://issues.jboss.org/browse/WFLY-2809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Frank Cornelis
>            Assignee: Stefan Guilhen
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>         Attachments: 0001-integration-test-for-JACC-PolicyContext.patch
>
>
> Calling
> {code}
> PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> {code}
> within a @Stateless session bean gives an exception.
> I've created an integration test to reproduce 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 issues at jboss.org  Fri Jan 31 16:25:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 16:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1809) The security subsystem
 plugins use deprecated Infinispan API
In-Reply-To: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497821.1375428478000.26844.1391203528693@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940620#comment-12940620 ] 

Jason Greene commented on WFLY-1809:
------------------------------------

I'll take that as a no :)
                
> The security subsystem plugins use deprecated Infinispan API
> ------------------------------------------------------------
>
>                 Key: WFLY-1809
>                 URL: https://issues.jboss.org/browse/WFLY-1809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: NadirX
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> org.jboss.as.security.plugins.JNDIBasedSecurityManagement uses a deprecated way of configuring an Infinispan cache which must 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 issues at jboss.org  Fri Jan 31 16:25:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 16:25:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1809) The security subsystem
 plugins use deprecated Infinispan API
In-Reply-To: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497821.1375428478000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497821.1375428478000.26847.1391203528890@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1809:
-------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> The security subsystem plugins use deprecated Infinispan API
> ------------------------------------------------------------
>
>                 Key: WFLY-1809
>                 URL: https://issues.jboss.org/browse/WFLY-1809
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: NadirX
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> org.jboss.as.security.plugins.JNDIBasedSecurityManagement uses a deprecated way of configuring an Infinispan cache which must 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 issues at jboss.org  Fri Jan 31 16:31:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 16:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1789) Fix host binding of tests
 involving GossipRouter
In-Reply-To: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530964.1391202692000.26853.1391203888880@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1789:
--------------------------------------

    Description: 
Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
 

  was:
Tests like TUNNEL_Test and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
 


    
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
>                 Key: JGRP-1789
>                 URL: https://issues.jboss.org/browse/JGRP-1789
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of 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 issues at jboss.org  Fri Jan 31 16:31:29 2014
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 31 Jan 2014 16:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2635) HTTP Management Interface
	Configuration
In-Reply-To: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527655.1386765053000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527655.1386765053000.26857.1391203889197@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940621#comment-12940621 ] 

Darran Lofthouse commented on WFLY-2635:
----------------------------------------

Sub tasks will be fine but some time will be needed to plan the overall structure first.
                
> HTTP Management Interface Configuration
> ---------------------------------------
>
>                 Key: WFLY-2635
>                 URL: https://issues.jboss.org/browse/WFLY-2635
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Various configuration items are required for the HTTP Management interface, this is a parent task to combine 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 issues at jboss.org  Fri Jan 31 16:31:29 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 16:31:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1789) Fix host binding of tests
 involving GossipRouter
In-Reply-To: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530964.1391202692000.26859.1391203889350@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1789:
--------------------------------------

    Description: 
Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
- a property gossip_router_hosts which specifies the gossip router hosts the client can connect to

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
 

  was:
Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
- a GosspiRouter which binds to a certain host address and port
- a GossipRouter client whose TUNNEL protocol binds to a certain host address and port

If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:

{noformat}
------------- startRouter -----------
-- starting GossipRouter on 127.0.0.1[23003]

------------- testConnectThree -----------
-------------------------------------------------------------------
GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
-------------------------------------------------------------------
605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
{noformat}

TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
 


    
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
>                 Key: JGRP-1789
>                 URL: https://issues.jboss.org/browse/JGRP-1789
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of 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 issues at jboss.org  Fri Jan 31 16:37:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 16:37:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2838) Revisit default mod_cluster
 metric for WildFly 8
In-Reply-To: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530685.1391028993000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530685.1391028993000.26864.1391204248877@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940622#comment-12940622 ] 

Jason Greene commented on WFLY-2838:
------------------------------------

I think its hard to determine based on number of requests because it all depends on how heavy the user code is in the context of a request.

CPU time is a pretty good value to use IMO. We could still have a watermark that the user could override. Alternatively it could get fancier and calculate the amount of CPU time used by the I/O threads and the worker pool saturation. That would require deeper OS integration and more work than we have time left.
                
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
>                 Key: WFLY-2838
>                 URL: https://issues.jboss.org/browse/WFLY-2838
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity.. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 16:41:28 2014
From: issues at jboss.org (Richard Achmatowicz (JIRA))
Date: Fri, 31 Jan 2014 16:41:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1789) Fix host binding of tests
 involving GossipRouter
In-Reply-To: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530964.1391202692000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530964.1391202692000.26866.1391204488719@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940623#comment-12940623 ] 

Richard Achmatowicz commented on JGRP-1789:
-------------------------------------------

It also would not hurt to print out the actual bind address and port used to start the GossipRouter in the test. Aids debugging.
                
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
>                 Key: JGRP-1789
>                 URL: https://issues.jboss.org/browse/JGRP-1789
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.13
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.2.13
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of 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 issues at jboss.org  Fri Jan 31 16:53:28 2014
From: issues at jboss.org (arjan tijms (JIRA))
Date: Fri, 31 Jan 2014 16:53:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2854) '**' role incorrectly returns
 false from isUserInRole when user is authenticated
In-Reply-To: <JIRA.12530966.1391205153441@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530966.1391205153441@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530966.1391205153441.26878.1391205208816@jira02.app.mwc.hst.phx2.redhat.com>

arjan tijms created WFLY-2854:
---------------------------------

             Summary: '**' role incorrectly returns false from isUserInRole when user is authenticated
                 Key: WFLY-2854
                 URL: https://issues.jboss.org/browse/WFLY-2854
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 8.0.0.CR1
            Reporter: arjan tijms
            Assignee: Darran Lofthouse


When authentication has taken place in a web application such that {{HttpServletRequest#getUserprincipap}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.

This is not correct. According to Servlet 13.3:

{quote}
{noformat}
If the role-name of the security-role to be tested is ?**?, 
and the application has NOT declared an application security-role with 
role-name ?**?, isUserInRole must only return true if the user has been
authenticated;
{noformat}
{quote}

This is demonstrated by the following test:

https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/src/test/java/org/javaee7/jacc/contexts/SubjectFromPolicyContextTest.java#L76


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 16:53:29 2014
From: issues at jboss.org (arjan tijms (JIRA))
Date: Fri, 31 Jan 2014 16:53:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2854) '**' role incorrectly returns
 false from isUserInRole when user is authenticated
In-Reply-To: <JIRA.12530966.1391205153000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530966.1391205153000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530966.1391205153000.26882.1391205209331@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

arjan tijms updated WFLY-2854:
------------------------------

    Description: 
When authentication has taken place in a web application such that {{HttpServletRequest#getUserPrincipal}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.

This is not correct. According to Servlet 13.3:

{quote}
{noformat}
If the role-name of the security-role to be tested is ?**?, 
and the application has NOT declared an application security-role with 
role-name ?**?, isUserInRole must only return true if the user has been
authenticated;
{noformat}
{quote}

This is demonstrated by the following test:

https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/src/test/java/org/javaee7/jacc/contexts/SubjectFromPolicyContextTest.java#L76


  was:
When authentication has taken place in a web application such that {{HttpServletRequest#getUserprincipap}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.

This is not correct. According to Servlet 13.3:

{quote}
{noformat}
If the role-name of the security-role to be tested is ?**?, 
and the application has NOT declared an application security-role with 
role-name ?**?, isUserInRole must only return true if the user has been
authenticated;
{noformat}
{quote}

This is demonstrated by the following test:

https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/src/test/java/org/javaee7/jacc/contexts/SubjectFromPolicyContextTest.java#L76



    
> '**' role incorrectly returns false from isUserInRole when user is authenticated
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2854
>                 URL: https://issues.jboss.org/browse/WFLY-2854
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.CR1
>            Reporter: arjan tijms
>            Assignee: Darran Lofthouse
>              Labels: role, roles, security, servlet
>
> When authentication has taken place in a web application such that {{HttpServletRequest#getUserPrincipal}} does not return null, testing for role '**' using {{HttpServletRequest#isUserInRole}} returns false.
> This is not correct. According to Servlet 13.3:
> {quote}
> {noformat}
> If the role-name of the security-role to be tested is ?**?, 
> and the application has NOT declared an application security-role with 
> role-name ?**?, isUserInRole must only return true if the user has been
> authenticated;
> {noformat}
> {quote}
> This is demonstrated by the following test:
> https://github.com/arjantijms/javaee7-samples/blob/master/jacc/contexts/src/test/java/org/javaee7/jacc/contexts/SubjectFromPolicyContextTest.java#L76

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 17:01:28 2014
From: issues at jboss.org (=?UTF-8?Q?P=C3=ABtr_Andreev_=28JIRA=29?=)
Date: Fri, 31 Jan 2014 17:01:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2739) BeanDeploymentArchive for
 external (WFLY) modules added twice
In-Reply-To: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529135.1389387358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529135.1389387358000.26885.1391205688880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940417#comment-12940417 ] 

P?tr Andreev edited comment on WFLY-2739 at 1/31/14 5:01 PM:
-------------------------------------------------------------

Pull Request: https://github.com/wildfly/wildfly/pull/5838
                
      was (Author: pjotrovsky):
    Pull Request: https://github.com/wildfly/wildfly/pull/5828
                  
> BeanDeploymentArchive for external (WFLY) modules added twice
> -------------------------------------------------------------
>
>                 Key: WFLY-2739
>                 URL: https://issues.jboss.org/browse/WFLY-2739
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.CR1
>         Environment: Win7,CentOS6
>            Reporter: P?tr Andreev
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Final
>
>
> The Weld-WFLY integration adds a dependency on WFLY module twice if the application deployment unit is an EAR containg libs, ejbs, war, etc. It prevents an application having dependencies on a new Picketlink (PL) extension to be deployed since PL contains a portable extension which has to be injected within PL module. The Weld-validation of the second time injection  fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From issues at jboss.org  Fri Jan 31 17:39:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:39:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.26897.1391207968953@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2641:
-------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Aslak Knutsen
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Fri Jan 31 17:39:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:39:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.26900.1391207969334@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940627#comment-12940627 ] 

Jason Greene commented on WFLY-2641:
------------------------------------

We will revisit our test suite in WF9, including whether or not we stick with Arquillian.
                
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Aslak Knutsen
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Fri Jan 31 17:41:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2641) ARQ upgrade likely to cause
	test failures
In-Reply-To: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527781.1386844563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527781.1386844563000.26912.1391208089045@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene reassigned WFLY-2641:
----------------------------------

    Assignee: Jason Greene  (was: Aslak Knutsen)

    
> ARQ upgrade likely to cause test failures 
> ------------------------------------------
>
>                 Key: WFLY-2641
>                 URL: https://issues.jboss.org/browse/WFLY-2641
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Jason Greene
>            Priority: Blocker
>             Fix For: 9.0.0.CR1
>
>
> {code}
> testSimpleBundleWithWabExtension(org.jboss.test.osgi.example.webapp.WebAppTestCase)  Time elapsed: 0.028 sec  <<< ERROR!
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:290)
> 	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)
> {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 issues at jboss.org  Fri Jan 31 17:41:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:41:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2592) A server-to-server
 communication via outbound connection is not working
In-Reply-To: <JIRA.12526575.1385838719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526575.1385838719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526575.1385838719000.26915.1391208089208@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2592:
-------------------------------

    Priority: Critical  (was: Blocker)

    
> A server-to-server communication via outbound connection is not working
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2592
>                 URL: https://issues.jboss.org/browse/WFLY-2592
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>            Priority: Critical
>              Labels: ejb, remoting
>         Attachments: networktraffic, server-client.log, server-server.log
>
>
> A ejb invocation from a SLSB is configured similar to AS7 (EAP6) to call a remote server fail in WildFly with the ERROR message " EJBCLIENT000025: No EJB receiver available for handling".
> The logfiles of client(server) and remote-server are attached, also a WireShark dump of the related network traffic.
> A standalone client at the same machine is able to call the remote 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 issues at jboss.org  Fri Jan 31 17:43:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2774) Non-distributed,
 stateful web applications cannot be load balanced using sticky
 sessions
In-Reply-To: <JIRA.12529716.1389982010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529716.1389982010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529716.1389982010000.26921.1391208208789@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940628#comment-12940628 ] 

Jason Greene commented on WFLY-2774:
------------------------------------

This should be resolved once CR2 of undertow is included
                
> Non-distributed, stateful web applications cannot be load balanced using sticky sessions
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2774
>                 URL: https://issues.jboss.org/browse/WFLY-2774
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 8.0.0.Final
>
>
> In AS7, one could configure a load balancer with sticky sessions to support load balancing for non-distributed web applications.
> While the distributed session manager supports parsing and formatting of the instance-id from/to the session id, the in-memory session manager does not.
> The use case for this are stateful web applications that do not require high-availability of state (e.g. a stateless web-app that uses container managed authentication), but would also like to scale beyond the capacity of a single 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 issues at jboss.org  Fri Jan 31 17:43:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:43:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase
 runs into intermittent failures
In-Reply-To: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494315.1371223824000.26924.1391208208963@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1535:
-------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> SSLEJBRemoteClientTestCase runs into intermittent failures
> ----------------------------------------------------------
>
>                 Key: WFLY-1535
>                 URL: https://issues.jboss.org/browse/WFLY-1535
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 9.0.0.CR1
>
>
> SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsDiv&buildTypeId=bt27.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 17:45:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:45:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-342) Reenable
 ClusteredSingleSignOnTestCase test to work with Undertow
In-Reply-To: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471898.1344331018000.26930.1391208329479@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-342:
------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Reenable ClusteredSingleSignOnTestCase test to work with Undertow 
> ------------------------------------------------------------------
>
>                 Key: WFLY-342
>                 URL: https://issues.jboss.org/browse/WFLY-342
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Kabir Khan
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 9.0.0.CR1
>
>         Attachments: ClusteredSingleSignOnTestCase1.html, ClusteredSingleSignOnTestCase2.html, ClusteredSingleSignOnTestCase3.html
>
>
> Test have been @Ignored until Undertow implements SSO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 17:47:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:47:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2821) Intermittent failures in EE
 resource injection tests
In-Reply-To: <JIRA.12530438.1390848308000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530438.1390848308000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530438.1390848308000.26942.1391208448746@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2821:
-------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.Final)

    
> Intermittent failures in EE resource injection tests
> ----------------------------------------------------
>
>                 Key: WFLY-2821
>                 URL: https://issues.jboss.org/browse/WFLY-2821
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: David Lloyd
>             Fix For: 9.0.0.CR1
>
>
> The set of 5 failures shown below are recurring intermittently in the WF testsuite:
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=8698&buildTypeId=WF_MasterIgnoreWindows&tab=buildResultsDiv
> org.jboss.as.test.integration.ee.injection.resource.enventry
>  EnvEntryInjectionTestCase.testNonExistantResourceCannotBeLookedUp	
>  org.jboss.as.test.integration.ee.injection.resource.noncomponent
>  NonComponentResourceInjectionTestCase.testBindingDoesNotExist	
>  org.jboss.as.test.integration.ee.injection.resource.persistencecontextref
>  PersistenceContextRefTestCase.testCorrectPersistenceUnitInjectedFromAnnotation2	
>  PersistenceContextRefTestCase.testCorrectPersistenceUnitInjectedFromPersistenceUnitRef	
>  PersistenceContextRefTestCase.testCorrectPersistenceUnitInjectedFromRefInjectionTarget2	

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From issues at jboss.org  Fri Jan 31 17:49:28 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:49:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-324) xinclude support in the
	management model
In-Reply-To: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446086.1314912041000.26947.1391208568917@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-324:
------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)
                       (was: 8.0.0.Final)

    
> xinclude support in the management model
> ----------------------------------------
>
>                 Key: WFLY-324
>                 URL: https://issues.jboss.org/browse/WFLY-324
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jason Greene
>             Fix For: 9.0.0.CR1
>
>
> Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified 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 issues at jboss.org  Fri Jan 31 17:49:29 2014
From: issues at jboss.org (Jason Greene (JIRA))
Date: Fri, 31 Jan 2014 17:49:29 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-324) xinclude support in the
	management model
In-Reply-To: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446086.1314912041000.26959.1391208569571@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940629#comment-12940629 ] 

Jason Greene commented on WFLY-324:
-----------------------------------

I have a prototype for this, but it requires further discussion. Deferring to 9
                
> xinclude support in the management model
> ----------------------------------------
>
>                 Key: WFLY-324
>                 URL: https://issues.jboss.org/browse/WFLY-324
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jason Greene
>             Fix For: 9.0.0.CR1
>
>
> Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified 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 issues at jboss.org  Fri Jan 31 18:31:28 2014
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 31 Jan 2014 18:31:28 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2580) keytool-maven-plugin does not
	work on JDK8
In-Reply-To: <JIRA.12526163.1385474426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12526163.1385474426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12526163.1385474426000.26965.1391211088721@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940631#comment-12940631 ] 

Tomaz Cerar commented on WFLY-2580:
-----------------------------------

My branch with fix for JDK8 https://github.com/ctomc/keytool-maven-plugin
                
> keytool-maven-plugin does not work on JDK8
> ------------------------------------------
>
>                 Key: WFLY-2580
>                 URL: https://issues.jboss.org/browse/WFLY-2580
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Tomaz Cerar
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.Final
>
>
> JDK8 has changed JarSigner package / class location
> upstream issue https://jira.codehaus.org/browse/MKEYTOOL-35

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

